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Chapter  One:  Overview 

1.1    Introduction 

Prolog  is  a  language  for  logic  programming.  It  uses  a  backward  reasoning, 
depth-first  search  algorithm  for  evaluating  its  goals.  Because  its  rule  structure  is 
similar  to  grammar  rules  and  its  search  algorithm  is  similar  to  the  LL(1)  parsing 
algorithm,  Prolog  is  an  excellent  language  for  developing  parsers  by  using  gram- 
mar rules  lClo84l  [Coh&4]  [Col85j  /Ste86l  IWarSOl.  Several  grammar  rules  have 
been  introduced  for  parsing  in  Prolog.  The  most  popular  approach  is  the  Definite 
Clause  Grammar  (DCG)  [Klu85/  iPerSOl.  Definite  Clause  Grammars  are  a  general- 
isation of  Context  Free  Grammars  (CFG)  in  which  the  features  are  extended  in 
two  ways:  the  use  of  compound  terms  as  arguments  and  the  use  of  semantic  con- 
dition expressions. 

At  present,  the  only  documentation  available  for  C-Prolog  in  the  Computer 
Science  Department  at  Kansas  State  University  is  the  C-Prolog  user's  manual 
which  does  not  cover  the  use  of  a  DCG  in  Prolog.  Thus,  the  first  goal  of  this 
report  is  to  establish  both  tutorial  and  user's  references  for  the  use  of  the  DCG 
rule  notations  in  C-Prolog.  Secondly,  this  report  presents  a  sample  problem  as  an 
example  to  illustrate  the  use  of  a  DCG  for  Prolog  parsing. 

Chapter  Two  of  this  report  introduces  the  use  of  Definite  Clause  Grammars, 
it  also  presents  several  examples  to  illustrate  the  techniques  of  transforming  a 
CFG  to  a  DCG  and  a  DCG  to  a  C-Prolog  program.  To  evaluate  the  use  of  a  DCG, 
an   implementation   with   the   use   of   a    DCG    is   written   In   C-Prolog.    For 
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comparison,  another  implementation  without  the  use  of  a  DCG  is  done  using 
Turbo  Prolog.  Both  implementations  are  for  the  same  problem  domain—  a  form 
of  the  predicate  logic. 

Two  different  approaches  for  the  evaluation  of  use  of  a  DCG  are  reported. 
They  are  syntactical  measurements  and  subjective  evaluation.  Syntactic  measure- 
ment reports  the  total  number  of  predicates,  production  rules,  system  calls,  and 
called-predicates.  A  discussion  of  the  computed  syntacticalal  complexity  of  both 
programs  is  given.  The  second  approach  is  a  subjective  evaluation  of  the  ease  of 
program  development  and  coding  from  the  perspective  of  a  programmer.  A  con- 
clusion on  the  use  of  a  DCG  for  parsing  in  Prolog  is  made  based  on  the  evaluation 
above. 


1.2    Organization 

Chapter  Two  presents  the  fundamental  concept  lying  behind  the  use  of  a 
DCG  for  parsing.  The  first  part  gives  a  general  idea  about  the  structure  of  Prolog, 
and  how  Prolog  relates  to  the  parsing.  The  second  part  is  an  introduction  to 
Definite  Clause  Grammars.  Several  examples  are  presented  as  illustrations  of  the 
use  of  a  Definite  Clause  Grammar. 

Chapter  3  is  a  case  study.  It  explains  the  problem  domain  for  the  imple- 
mentation project,  the  selection  of  Prolog  tools,  and  the  evaluation  of  the  use  of  a 
DCG  for  Prolog  parsing. 


1.3    Results 

DCG  is  an  extension  to  a  CFG.  The  DCG  provides  a  good  technique  for  the 
translation  of  a  problem  statement  to  a  Prolog  program.  From  the  aspect  of 
implementation  design,  the  use  of  DCG  for  Prolog  parsing  is  desirable  despite  the 
possibility  of  larger  syntacticalal  size  than  Prolog  coding  without  the  use  of 
Definite  Clause  Grammars. 

To  provide  users  documentation  about  the  use  of  a  DCG  for  parsing  in  Pro- 
log, a  formal  grammar  (in  BNF  notation)  denning  the  structure  of  a  DCG  is  writ- 
ten. Furthermore,  Section  2.3  of  this  report  can  serve  as  a  tutorial  lesson. 
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Chapter  Two:  The  Use  of  a  DCG  in  Prolog 

2.1   The  Structure  of  Prolog 

A  Prolog  program  is  expressed  as  a  collection  of  rules,  facts,  and  goals.  A 
rule  is  a  clausal  form  with  head  and  body  (a  sequence  of  subgoals),  and  it  is 
written  as: 

A  :-  Bl,  B2,  B3,  Bn.  (n>-0) 

Without  the  body,  the  clause  is  called  a  fact  ,  and  a  goal  is  the  form  without  the 
head.  The  annotations  are: 

A.  (fact) 

Bl,  B2,  B3,  Bn.     (goal) 

The  interpreter  of  Prolog  is  based  on  the  resolution  theorem  prover  lRob65] 
using  clauses  to  accomplish  its  goal  [Klu85j  [Clo84l.  For  example,  Figure  2.1.1  is 
a  simple  Prolog  program  defining  "sibling".  Variable  arguments  begin  with  capital 
letters.  Goal  searching  for  "sibling"  using  resolution  is  shown  in  Figure  2.1.2. 


la)  sibling(P.Q)  :- 

POQ,  parents(p(F,Ml),P),  parents(p(F,M2),Q). 
lb)  sibling(P.Q)  :- 

POQ,  parents(p(Fl,M),P),  parents(p(F2,M),Q). 

2a)  parents(p(joe,rose),tom). 
2b)  parents(p(joe,rose),dale). 

Goal: 

sibling(tom,X). 


Figure  2.1.1:  A  simple  Prolog  program  denning  "sibling". 

Prolog  starts  with  a  goal  statement  "sibling(tom,X)"  and  searches  for  a 
clause  whose  head  matches  the  goal  (sibling(P.Q)  of  la  in  Figure  2.1.2),  then 
unifies  (binds)  variable  arguments  as  necessary  to  make  matches  succeed.  The 
body  of  the  instantiated  clause  is  added  to  the  goals  to  be  satisfied,  and  Prolog 
tries  to  match  this  new  goal  to  another  clause,  and  so  on.  The  matching  mechan- 
ism described  here  is  known  as  resolution  [Ric83].  Each  step  of  <I>,  <II>, 
and  <III>  is  a  resolution.  For  instance,  in  step  <I>,  the  resolution  of  two 
rules,  sibling(tom,X)  and  rule  la),  results  in  a  third  rule 

sibling(tom,X)  :- 

tomOX,  parents(p(F,Ml),tom),  parents(p(F,M2),X). 

In  this  example,  the  goal  succeeds  and  unifies  with  "dale". 


sibling(tom.X) 

I 
<I>  I 

la)*   I  tom/P" 
I  X/Q 
V 

sibling(tom,X)  :- 

tom<  >X,  parents(p(F,Ml).tom),  parents(p(F,M2).X). 
I 
<II>  2a)   I   F/joe,  Ml/rose 

I 
V 

sibling(tom,X)  :-    tomOX.  parents(p(joe.M2),X). 
/  I 

2a)  /  joe/joe  I 

<m>  /  M2/rose  2b)     I  joe/joe 

/  X/tom  I  M2/rose 

v  I  X/dale 

tom<  >  torn  —>  FAIL  **•  I 

V 
X-dale  —  >    SUCCEED 

*    "N)*  indicates  rule  N)  is  used  for  resolution 

**  "Formal-var/Actual-var"  indicates  the  variables  unification 

*"  Backtracking  occurs  as  search  fails 

Figure  2.1.2:  Resolution  search  of  goal  in  Figure  2.1.1 


At  any  stage,  if  no  matching  fact  or  matching  clause  head  can  be  found,  Pro- 
log will  reject  the  most  recently  matched  clause  and  undo  any  instantiation  made 
in  that  match.  Next,  Prolog  will  reconsider  the  previous  goal  which  matched  the 
rejected  clause,  and  try  to  resatisfy  the  goal.  This  attempt  to  fond  an  alternative 
way  to  resatisfy  previous  goals  is  called  backtracking.  For  example,  in  Figure 
2.1.2,  the  backtracking  occurs  in  step  <IH>  as  the  searching  fails  (because  a  per- 
son cannot  be  a  sibling  of  himself/herself).   Thus,  Prolog  aborts  the  instantiation 


of  2a),  returns  to  the  most  recent  backtracking  point  and  tries  the  alternative 
(rule  2b). 

Figure  2.1.3  shows  the  searching  route  for  Figure  2.1.2  using  a  stack  model. 
As  each  goal  is  expanded  it  links  to  its  sequence  of  subgoals.  Each  goal  is  retained 
as  a  possible  backtracking  point,  denoted  with  an  "*".  Each  subgoal  is  expanded 
until  it  matches  an  existing  fact. 


sibling 
(tom.X) 


lal* 


tom/P 
X/Q 


torn  <>  X 


parents 
(p(F,Ml),tom) 


parents 
(p(F,M2),X) 


ML 


F/joe 
Ml /rose 


parents 
(p(joe,rose),tom) 


parents 
(p(joe, rose), torn] 


torn  <>  torn 


*•  FAIL 


parents 
(p(joe,  rose),  dale) 


X  "  dali  SUCCEED 


Figure  2. 1.3:       Stack  model  of  searching  route  for  Fig.  2. 1. 1 


The  searching  routes  of  Figure  2.1.3  can  be  further  expanded  as  a  tree-like 
structure  shown  in  Figure  2.1.4.  It  is  noted  that  this  entire  Prolog  performance 
uses  depth-first  strategies—  top-down  and  left  to  right.  The  control  structure  of 
Prolog  matches  that  of  a  recursive-descent  top-down  parser  (LL(l)  parser) 
[Aho86j  [Bar86].  All  of  these  indicate  that  Prolog  uses  a  mechanical  searching 
algorithm  which  enables  Prolog  to  be  an  excellent  language  for  parsing. 


siblingCtom.X) 

'  '  \ 

v  V  \ 

POQ      parents(p(F,Ml),P)  \ 
\ 


/  v 

/  parents(p(F,M2),Q) 


/ 


v  /I 
parents(p(joe,rose),tom)  /  I 
/*                   I 

/  FAIL  I 

/  I 


parents(p(joe,rose),tom) 


I  SUCCEED 

v 
parents(pCjoe,rose),dale) 


> 

Note:  *  -=  backtracking  point 

Figure  2.1.4:  Searching  tree  for  Figure  2.1.1 
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2.2    Definite  Clause  Grammars 

Context  Free  Grammars  (CFG)  is  a  fundamental  class  of  grammars.    The 
production  of  CFG  is  expressed  as 

Head  —  >  Body 

where  the  Head  is  a  non-terminal  and  the  Body  is  a  sequence  of  terminals  and/or 
non-terminals.  CFG  has  some  properties  which  are  important  to  language  pars- 
ing. It  specifies  the  syntax  of  language  in  a  concise  and  modular  way.  It  also 
defines  the  embedded  recursive  structure  of  the  language  constructs  lAhoS6] 
lBarS6]. 

Definite  Clause  Grammars  (DCG)  are  usually  attributed  to  Pereira  and  War- 
ren whose  work  was  inspired  by  Colmerauer  &  Kowalski's  idea  [Col75]  [Ste86j. 
The  technique  of  DCG  involves  a  simple  generalisation  of  a  CFG.   DCG  extends 
CFG  annotations  in  two  basic  ways: 
1)     DCG  allows  non-terminals  to  have  arguments.   Also,  an  argument  can  be  a 

compound  term.  A  compound  term  has  the  form  of 

X(Yl,Y2,...,Yi), 

where  i  >=  1.  X  is  similar  to  the  record  name  in  Pascal-like  language,  and 
Yi  is  the  field.  The  structure  of  Yi  can  be  a  number,  a  string,  a  list,  or  even 
another  compound  term.  For  instance,  the  expression, 

book(title,autlior,publisher(nanie^ddress),editiou([l964,1970,1979,1987])),  is 
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a  valid  compound  term. 

The  following  is  an  example  of  using  the  compound  term  for  non-terminal 
in  a  rule: 

rel_expCrexp([Op,Xl,X2])) 

->     exp(Xl),  relop(Op),  exp(X2). 

The  clause  above  defines  a  relational  expression  "rel_exp"  as  composed  of  a 
simple  expression  "exp",  then  a  relational  operator  "relop"  followed  by 
another  simple  expression.  The  argument  "rexp([Op,Xl,X2])"  records  the 
syntactic  structure  of  the  relational  expression.  It  is  the  parse  tree  of 
"rel_exp".  This  extension  technique  is  very  useful  in  keeping  track  of  con- 
struct quantities  in  the  course  of  parsing. 

2)  In  DCG,  extra  condition  expressions  are  enclosed  within  a  pair  of  curly 
brackets  and  remain  in  the  right-hand  side  of  the  grammar  rule.  The  expres- 
sions within  the  brackets  are  not  involved  in  the  underlying  token  consump- 
tion in  the  parsing.  Rather,  the  extra  condition  provides  some  auxiliary  con- 
ditions to  restrict  the  constituents  accepted,  e.g. 

digit_number(Number)  —  > 

[Char],  {Char>48,  Char<60,  Number  is  Char-49}. 

The  parse  phrase  of  the  example  above  consists  of  one  component  "[Char]" 
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only.  The  declarative  semantics  of  the  rule  can  be  expressed  as  "the 
unification  of  digit_number(X)  is  true  only  if  the  parsed  token,  Char,  is  a 
digit  of  '0'  to  '9',  then  the  corresponding  integer  is  computed  and  reserved  in 
the  argument". 

Occasionally,  an  extra  condition  is  followed  immediately  after  a  particular 

parse  phrase  to  perform  a  conditional  test  on  the  argument  or  token  of  that 

phrase,  e.g. 

lexpmore(Lop,Ll  ,V  1  ,Lf  ,Vf ) 

->    [Lop],  )Lop='eqv'},  lexpO(L2,V2), 

fevallog(V,Vl,V2,eqv),  Vf=V,  Lf=lexp([eqv,Ll,L2])} 

In  the  example  above,  the  semantic  action  (Lop='eqv'j  is  a  conditional  test 
for  variable  "Lop".  The  rest  of  the  rule  is  processed  only  if  the  test  succeeds. 

These  extra  condition  expressions  are  akin  to  the  semantic  rules  (semantic 
actions)  in  attribute  grammars  [Coh85].  may  have  inherited  and/or  syn- 
thesized attributes  [Aho86j.  An  example  will  be  presented  in  the  next  section. 


11 


2.3  Examples  of  the  Use  of  a  DCG 

The  following  example  is  to  be  used  as  an  illustration  for  the  use  of  a  DCG 
throughout  the  entire  section.  Consider  the  notation, 

A1  +  A2  +  A3  +  ....  +  An     (n>0), 

which  can  be  interpreted  as: 

it  is  the  sum  of  integers  Al,  A2,  __  ,  and  An,  or 

it  is  the  concatenation  of  strings  Al,  A2, ,  and  An. 

Figure  2.3.1  is  a  Context  Free  Grammar  for  the  pattern  described  above,  and  it 
parses  the  expressions, "  Art  +  Of  +  Prolog  "  and  "2  +  4  +  6  ",  correctly. 


expression  —  >    sum_expression 
expression  — >    string_expression 

sum_expression  —  >    int_variable  more_sum_exp 
string_expression  —  >    str_variable  more_str_exp 

more_sum_exp  —  >    '+'   int_variable  more_sum_exp 
more_sum_exp  —  >    null 

more_str_exp  —  >    '+'   str_variable  more_str_exp 
more_str_exp  —  >    null 

int_variable  —  >  2 

int_variable  —  >  4 

int_variable  —  >  6 

str_variable  —  >  "Art" 

str_variable  —  >  "Of" 

str_variable  —  >  "Prolog" 

Figure  2.3.1:  Context  Free  Grammar  for  pattern   'Al  +  A2  +  ....  +  An' 
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In  DCG,  a  terminal  is  enclosed  within  a  pair  of  square  brackets,  such  as  [+] 
=  '+',  [2]  ==  2,  [Pro]  ==  "Pro",  []  =  null.  A  comma  ','  is  used  as  the  delimiter  if 
there  is  more  than  one  literal  in  the  body  of  the  rule  and  a  period  is  an  end-mark 
for  a  production  rule.  With  few  changes  in  notations,  the  CFG  in  Figure  2.3.1  is 
transformed  to  a  DCG  which  is  listed  in  Figure  2.3.2.  The  modified  grammar 
(step  1)  is  still  a  CFG  but  it  Is  written  with  DCG  notation. 


expression  —  >    sum_expression. 
expression  —  >    str_expression. 


sum_expression  — >    int_variable.  more_sum__exp. 
string_expression  —  >    str_variable.  more_str_exp. 

more_sum_exp  —  >    [+].  int_variable,  more_sum_exp. 
more_sum_exp  —  >    []. 

more_str_exp  —  >    [+],  str_variable,  more_str_exp. 
more_str_exp  —  >    []. 

int_variable  — >  [2]. 

int_variable  — >  [4]. 

int_yariable  —  >  [6]. 

str_variable  —  >  ["Art"]. 

str_variable  —  >  ["Of"]. 

str_variable  —  >  ["Prolog"]. 

Figure  2.3.2:  DCG  (step  1)  for  pattern  Al  +  A2  +  ....  +  An 


In  Figure  2.3.2,  the  predicates  "sum_expression"  and  "string_expression" 
have  similar  syntactic  structures  representing  different  semantics.  To  combine 
similar  predicates  as  one,  an  argument  (with  parameter  Type  )  is  added  to  each 
non-terminal  of  the  predicates  above  to  reflect  their  semantic  differences.  The 
modified  DCG  is  shown  in  Figure  2.3.3.   This  new  grammar  (step  2)  is  no  longer 
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a  CFG.   It  is  context  sensitive.  The  parameter  "Type"  is  used  to  express  the  con- 
text constraint  that  the  "variable"  tokens  all  have  the  same  "Type's. 

Note  that  the  language  which  is  recognized  is  still  the  sdame,  but  it  is 
described  by  a  smaller  context  sensitive  DCG  rather  thatn  a  larger  CFG. 

expression  —  >  variable(Type).  more_exp(Type). 

more_exp(Type)  — >    [+].  variable(Type),  more_exp(Type). 
more_exp(Type)  —  >    []. 

variable(integer)  —  >    [2]. 
variable(integer)  —  >    [4]. 
variable(integer)  —  >    [6]. 
variable(string)  —  >    ["Art"]. 
variable(string)  —  >    ["Of"]. 
variable(string)  —  >    ["Prolog"]. 

Figure  2.3.3:  DCG  (step  2)  for  pattern  'Al  +  A2  +  ....  +  An 

In  order  to  have  the  function  of  execution  as  well  as  parsing,  the  DCG  in 
Figure  2.3.3  is  extended  to  have  extra  conditions.  An  extra  condition  consists  of  a 
set  of  semantic  expressions  which  were  enclosed  within  a  pair  of  curly  brackets. 
The  alternatives  within  semantic  expressions  can  be  separated  by  semicolon  ";" 
characters. 

To  perform  the  computation  (add  or  concatenate)  for  Figure  2.3.3,  one  needs 
to  know  the  value  of  every  variable.  Also,  the  result  of  each  operation  should 
be  saved  for  the  later  use.  Therefore,  a  parameter  reflecting  the  value  of  each 
variable  is  added  to  each  non-terminal.  The  rewritten  DCG  for  Figure  2.3.4  with 
the  extension  of  extra  condition  is  listed  as  follows: 
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expression(Result)  —  > 

variable(Type.Vall),  more_exp(Type.Val2), 
I  Val2-[],  Result  -  Vail; 
Type  -  "integer".  Result  -  Vail  +  Val2; 
Type  =  "string".   Result  -  Vail  cat  Val2    }.  ** 

more_exp(Type.Val)  — > 

[].  (Val  -  []}. 
more_exp(Type,Val)  —  > 

[+].  variable(Type.Vall),  more_exp(Type,Val2). 
(   Val2  -  [].  Val  =  Vail: 
Type  -  "integer",  Val  -  Vail  +  Val2; 
Type  -  "stringt".  Val  -  Vail  cat  Val2      ) 

variable(integer,2)  —  >    [2]. 
variable(integer,4)  —  >    [4]. 
variable(integer,6)  —  >    [4]. 
variable(string,"Art")      —  >    ["Art"]. 
variable(string,"Of")       —  >    ["Of"]. 
variable(string,"Prolog")  —  >    ["Prolog"]. 

**   "cat"  —  concatenation  of  strings. 
Figure  2.3.4:  DCG  (step3)  for  pattern  'Al  +  A2  +  ....  +  An' 


The  declarative  semantics  for  the  extra  condition  in  predicate  expression  is  read 
as: 

IF      it  is  a  simple  case  (Val2=[])     THEN 

the  result  (Result)  is  the  attribute  of  first  variable  (Vail). 

ELSE 
IF     the  type  of  variable  is  an  integer  THEN 

compute  the  sum  (Result)  of  two  variables  (Vail  and  Val2). 

ELSE 
IF     the  type  of  variable  if  a  string  THEN 

compute  the  concatenation  (Result)  of  two  variables  (Vail  and  Val2). 

As  mentioned  in  the  previous  section,  a  DCG  has  the  features  of  an  attribute 
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grammar.  The  attributes  Vail,  Val2  and  Type  of  Variable  in  predicate  expres- 
sion are  terminals  whose  values  are  supplied  by  the  lexical  analyzer,  and  the 
value  of  Result  is  computed  from  the  values  of  its  children  nodes—  Vail  and 
Val2.  Thus,  Type  (of  the  "variable"  in  predicate  "expression"),  Vail,  Val2  and 
Result  are  synthesized  attributes.  The  Type  in  "more_exp"  is  an  inherited  attri- 
bute because  its  value  depends  upon  the  instantiation  of  the  Type  for  "variable" 
in  predicate  "expression"  [Aho85]. 

It  is  often  useful  for  grammar  rules  to  compute  the  parse  tree  of  the  recog- 
nized input  stream.  With  the  extension  of  the  compound  term  nonterminal,  DCG 
has  the  capability  of  providing  structure  information  about  the  constructs  at  each 
node  during  parsing.  In  Figure  2.3.4,  a  compound  term  reflecting  the  parsing 
structure  is  added  to  each  literal  expression  as  a  parameter. 

Of  course,  one  would  not  usually  compute  both  the  expression  value  and  its 
parsing  structure,  but  these  are  included  for  completeness  of  the  example.  More 
commonly  an  interpretation  of  an  input  stream  (or  value  in  the  example)  would 
be  computed  from  the  parse  tree. 

There  are  two  cases  for  predicate  "variable"  In  Figure  2.3.5.  Case  II  is 
modified  from  Case  I  for  the  generalisation  purpose. 
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expression(Result,  expression(Tree))  —  > 

variable(Type.Vl.Treel).  rnore_exp(Type.V2.var(Treel).Tree,Op), 
(  Vl=[].  Result  -  Val2  ; 
Type  -  "integer".  Result  -  VI  +  V2.  Op  »  sum  ; 
Result  =  VI  cat  V2,  Op  -  cat  ). 

more_exp(Type.Val,Lastree,Tree,Op)  —  > 

[].  {Val  -  [].  Tree  -  Lastree  }. 
more_exp(Type.Val.Lastree,Tree,Op)  —  > 
[+].  variable(Type.Vl.Treel). 

more_exp(Type,Val2,[Lastree.op(Op).var(Treel)],Tree,Op). 
{    Val2  -[].  Val  -  Vail; 

Type  -  "integer",  Val  -  Vail  +  Val2  : 
Val  -  Vail  cat  Val2  ) 

%  Case  I 

% 

variable(integer.2,integer(2))  —  >    [2]. 
variable(integer.4,integer(4))  —  >    [4]. 
variable(integer,6,integer(6))  —  >    [4]. 
variable(string,"Art",string("Art"))         —  >    ["Art"]. 
variable(string,"Of",string("Of"))  ->    ["Of"]. 

variable(string,"Prolog",string("Prolog"))  —  >    ["Prolog"]. 

%  CaseH 

% 

variable(integer,X,integer(X))  —  >    [X],  (is_integer(X)}. 
variable(string.X,string(X))  — >  [X],  (is_string(X)). 

Figure  2.3.5:  DCG  (step  4)  for  pattern  "Al  +  A2  +  ....  +  An" 


In  Figure  2.3.5,  the  parameter  Op  in  predicate  more_exp  is  an  attribute  for 
the  type  of  operation  (such  as  sum,  or  cat).  The  DCG  of  step  4  is  readily 
translated  into  Prolog  notations.  In  C-Prolog,  each  symbol  of  "  — >  ", "  □  ",  and  " 
{}  "  has  a  corresponding  system  operator  (with  exactly  the  same  notation).  The 
"integer",  "string",  and  "sum"  appearing  inside  the  extra  condition  are  atomic 
strings  in  C-Prolog,  where  an  atomic  string  can  be  expressed  by  itself  along  or 
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within  a  pair  of  single  quotes.  Since  the  strings  Art,  Of,  and  Prolog  are  constant, 
they  must  be  quoted  to  distinguish  from  the  variable  terms.  The  "cat"  operator  is 
supported  by  adding  an  extra  set  of  user-defined  rules.  The  "is_integerO"  and 
"is_stringO"  within  extra  conditions  of  predicate  "variable"  can  be  substituted  by 
the  system  functions  "integerO"  and  "atomO".  The  implemented  Prolog  program 
(excludes  the  scanner  part)  for  the  DCG  (with  case  II)  in  Figure  2.3.5  is  listed  in 
the  following: 


%   Main  control 

start  :- 

reconsult('pred.scan.pro').  %  file  "pred. scan. pro"  is  in  Appendix  II 

action('test.tutor'.user).  %  "test.tutor"  contains  an  input  string 


action(Infile.  Outfile)  :- 

seeQnfile). 

tell(Outfile). 

writeC  Input  tokens  ').  nl. 

writeC ').  nl, 

tab(6), 

getO(Ch). 

scan(Ch.Wordlist). 

seen,  nl,  nl. 

write('  Computation  ').  nl, 

writeC ').  nl. 

exp(Wordlist,Result,Tree). 

writeC  The  computed  result'),  nl, 

writeC     -=>     '), 

write(Result),  nl.  nl, 

writeC  Parse  tree  :   '),  nl, 

writree(Tree,6).  nl. 
action(_._)  :-  seen,  told. 

Figure  2.3.6:  Prolog  program  for  pattern  Al  +  A2  +  ....  +  An' 
(  To  be  continued  ) 
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%  Printer  facility 
% 

writree([XITail],Depth)  :- 

X-[],  !; 

X=variable(_),  nl.  tab(Depth+2),  write(X),  tab(3),  writreeCTail.Deptri); 

X=operator(_),  nl.  tab(Depth+2).  write(X).  writree(Tail.Depth); 

nl.  tab(Depth),  write('(  ').  Dl  is  Depth+2,  writree(X.Dl). 

nl,  tab(Depth+l).  write(')  ').  DO  is  Depth-2.  writree(Tail.DO). 
writree([]._). 


%  Parser 

% 

exp(Expression.Result.Tree)  :-      expression(Result,Tree,Expression.S). 

expression(Result,  Tree)  —  > 

var(Type.Vl.Trl).  more_exp(Type,V2,variable(Trl).Tree,Op), 
{  V2  -  [].  Result  =  VI  ; 
Type  -  integer.  Result  is  V1+V2,  Op  -=  sum  : 
cat(Vl,V2.Result).  Op  -  cat  }. 


more_exp(Type.Val,Ptree,Tree,Op)  —  > 

[+].  var(Type.Vl.Trl), 

more_exp(Type.V2.[Ptree.operator(Op).variable(Trl)].Tree.Op), 
{  V2  -  [],  Val  -  VI  ; 

Type  -  integer,  Val  is  VI  +  V2  ; 

cat(Vl.V2.Val)  }. 

more_erp(Type.Val,Ptree.Tree.Op)  —  >       [],  {Val  -  [].  Tree  =  Ptree}. 


var(integer,X,integer(X))  — >    [X],  {integer(X)}. 
var(string,X.string(X))   ->    [X],  {atom(X)}. 


cat(Sl,S2,Scat)  :-  name(Sl,Ll),  name(S2,L2), 

append(Ll.L2,Lcat),  name(Scat.Lcat). 

append([],L,L). 

append([XILl].L2,[XILcat])  :-  append(Ll,L2,Lcat). 

Figure  2.3.6:  Prolog  program  for  pattern  'Al  +  A2  +  ....  +  An'      (Continued) 
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The  following  is  a  list  of  terminal  output  from  Prolog  execution  of  an  input 
string  The  +  Art  +  Of  +  Prolog  +  by  +  Shapiro  [note]. 

%  prolog 

C-Prolog  version  1.4 

I  ?-  ['tutor.pro']. 

tutor. pro  consulted  3080  bytes  0.733333  sec. 

yes 

I  ?-  start. 

pred.scan.pro  reconsulted  2440  bytes  0.683333  sec. 

Input  tokens 

The  +  Art  +  of  +  Prolog  +  by  +  Shapiro 

Computation 


The  computed  result 
— >     ArlofPrologbyShapiro 

Parse  tree  : 

( 

( 
( 

variable(string(  Art)) 
operator(cat) 
variable(string(  of)) 
) 

operatorCcat) 
variableCstring(Prolog)) 
) 

operatorCcat) 
variableC  string(by) ) 
) 

operatorCcat) 
variableCstring(Shapiro)) 

yes 

I  ?-  halt. 

[  Prolog  execution  halted  ] 


■20- 


I.  " A  Z"  is  a  control  character  for  end-of-input  in  C-Prolog  (see  reference  [Clo84])). 
Thus.  "  A  Z"  appends  after  the  input  string  in  test  file  "test.tutor".  However,  user 
may  use  any  other  character  for  end-of-input  by  substituting  the  Asciicode  26      (" 

AZ")  in  scanner  file  with  the  code  corresponds  to  the  replacing  character,  for 
instance,  Ascii  26  is  replaced  by  46  if  a  "."  is  used  as  a  control  character  for  end-of- 
input. 

II.  It  always  has  the  same  operator  for  any  valid  input  string  in  the  example  of  'Al  + 
A2  +  ...  +  An',   the  input 

The  +  Art  +  of  +  Prolog  +  by  +  Shapiro 

is  equvalent  to 

(((((The  +  Art)  +  Of)  +  Prolog)  +  by)  +  Shapiro). 
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Chapter  3:  Case  Study 

3. 1  Overview 

The  objective  of  this  chapter  is  to  illustrate  the  use  of  a  Definite  Clause 
Grammar  in  Prolog  for  parsing  and  execution  of  a  sample  problem.  The  domain 
of  this  sample  problem  is  a  form  of  the  predicate  logic  presented  in  Gries  lGriS3/. 

In  this  study,  an  interpreter  for  the  sample  problem  is  implemented  in  C- 
Prolog  with  the  use  of  DCG.  For  comparison,  another  version  without  the  use  of 
DCG  is  done  using  Turbo  Prolog.  The  evaluation  of  the  use  of  a  DCG  involves 
the  measurement  of  the  program  size  Cor  program  complexity)  and  the  analysis 
of  the  Prolog  implementation.  The  former  is  determined  by  the  ratio  of  the  sum 
of  the  user-defined  function  calls  and  the  system  calls  over  the  number  of  predi- 
cates. In  the  latter  evaluation  is  made  in  terms  of  the  ease  of  program  design 
and  coding  during  the  course  of  implementation  from  the  perspective  of  a  pro- 
grammer. In  addition,  a  new  form  of  comparison  (the  implementation- 
similarity)  between  two  Prolog  versions  is  introduced  and  discussed. 


3.2  Selection  of  A  Prolog  Version 

Prolog  exists  in  a  number  of  different  implementations,  each  with  its  own 
semantic  and  syntactic  peculiarities  lWee86].      At  present,  there  are  four  imple- 
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mentations  available  in  the  Computer  Science  Department  at  Kansas  State 
University—  C-Prolog,  Turbo  Prolog,  Quintus  Prolog  (runs  on  ZEROX  A.I. 
workstation  1186),  and  AAAI  Prolog  (runs  on  Macintosh).  All,  but  Turbo  Pro- 
log, support  the  Definite  Clause  Grammar  notation.  Because  both  Quintus  Prolog 
and  AAAI  Prolog  were  not  fully  installed  and  Turbo  Prolog  was  used  for  other 
projects  [VenS7l  [CheS7l  at  the  time  author  started  this  study,  C-Prolog  was 
selected  for  the  example  with  the  use  of  DCG  and  Turbo  Prolog  was  chosen  as  a 
comparative  version  which  does  not  use  the  DCG. 

C-Prolog  runs  on  the  UNIX  operating  system  (BSD  4.3)  for  the  VAX 
11/780.  It  is  consistent  with  the  "standard  version"  described  by  Clocksin  & 
Mellish  (C&M  describe  a  core  Prolog  developed  at  Edinburg)  lCk>84].  C-Prolog 
provides  both  a  full  set  of  arithmetic  operators  and  a  set  of  operators  for 
dynamic  structures,  such  as  "functorO",  "-..",  and  "callO".  It  also  supports  the 
Definite  Clause  Grammar  rule  notations  with  operators  "— >",  "[]",  and  "{(" 
[Cpo86l.  Because  it  is  interpreted,  C-Prolog  has  slower  execution  speed  compared 
to  most  of  the  conventional  languages. 

Turbo  Prolog,  released  by  Boland  International,  runs  on  MS-DOS  for  IBM- 
compatible  Personal  Computers  [Bor86].  It  provides  several  convenient  facilities, 
such  as  a  user-friendly  interface  system,  full-screen  editing/tracing, 
graphics/windowing  capabilities  and  string  handling.  In  addition,  Turbo  Prolog 
provides  a  typing  system.  Users  are  required  to  define  the  types  and  domains 
just  as  they  do  in  Pascal  and  C.  This  feature  not  only  provides  the  compiler  with 
error-checking  capabilities  but  also  improves  the  performance  efficiency.   On  the 
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other  hand,  Turbo  Prolog  can  not  dynamically  create  a  structure  due  to  its  static 
typing  system.  The  typing  system  and  the  lack  of  DCG  built-in  predicates  keep 
Turbo  Prolog,  unlike  other  implementations,  far  away  from  the  C&M  standard. 
(Note:  Recently,  Boland  International  released  a  software  package  "Turbo  Prolog 
Tool  Box"  which  includes  a  preprocessor  of  DCG  rule  notations.  Another  similar 
translator  is  implemented  by  Watson  [Wat&7]  ). 


3.3  Sample  Problem 

The  problem  domain  for  the  Prolog  implementation  is  a  form  of  the  predi- 
cate logic  described  by  Gries  [GH83J.  Table  3.1  shows  the  source  grammar  (in 
Backus-Naur  Form)  denning  this  sample  domain. 
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<pred>     ::-     <simpred>     [<lop>   <simpred>]* 

<simpred>    ::-    "("    <  quant  >    ")"   I     <lexp> 

<quant>  ::=    "forall"    <quantbody>  I  "therexist"    <quantbody>  I 
"C"   "numberof"    <quantbody>    ")"   "="    <  const  > 

<quantbody>  ::=     <var>    ":"  "("    <ivar>    ".."    <ivar>    ")"  ":" 
<avar>   "["   <var>    "]"    <relop>    <  const  > 

<lexp>    :>    "not"    <lexp>  I    "("    <lexp>    ")"  I    <rexp> 

<  lop>     ::=    "and"  I  "or"  I  "xor"  I  "imp"  I  "eqv" 
<rexp>    ::=     <iexp>  I    <exp>  <relop>  <exp> 
<iexp>    ::-     <ivar>   "in"  "["    <iterm>    ".."    <iterm>    "]" 
<iterm>  ::-     <  const  >  I   <ivar> 

<exp>     ::-  <var>  I    <aexp> 

<relop>  ::=  '='  I  ">'  I  '<"  I  "<>"  I  ">-"  I  "<-" 

<aexp>    ::-  <avar>    "["    <iterm>    T 

<  const  >  ::-  (any  legal  integer) 
<ivar>    ::-  (any  defined  index  variable) 
<var>     ::-  {any  defined  variable) 
<avar>    ::-  (any  defined  array  variable) 

Table  3.1:  Grammar  for  predicate  logic  problem    (To  be  continued) 
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Notes: 

I  <term>    is  a  nonterminal, 
"term"   is  a  terminal  or  constant. 

[term]*   —   term  has  zero  or  more  occurrences. 

II  The  precedence  order  for  logical  operator  is 
"and"  >  "or"  >  "xor"  >  "imp"  >  "eqv". 

This  order  can  be  handled  by  grammars  or  by  implementation  itself. 

III  All  variables  names  like    <ivar>,    <var>,  and    <avar>   are  those  defined  and 
used  in  the  problem  statement. 


Table  3.1:  Grammar  for  predicate  logic  problem       (Continued) 

The  predicate  <pred>  is  defined  as  a  simple  predicate  <simpred> ,  or  it  is 
denned  as  a  <simpred>  followed  by  more  <simpred>s,  where  every  two  sim- 
ple predicates  are  connected  by  a  logical  operator.  The  precedence  of  logical 
operators  is  and  >  or  >  xor  >  imp  >  eqv.  The  latter  defines  the  predicate  of  a 
complex  form.  A  simple-predicate  <simpred>  can  be  a  quantification 
< quant >  or  a  relational  expression  <lexp>  associated  with  a  "not"  or  a  rela- 
tional operator,  e.g. 
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Sample  predicates: 

I>      ("not"  m).  (m  -  xyz).  (m  <  xyz),  (m  >  xyz) 

II  >     Universal  Quantification 

(Ai :  m  <  i  <  n  :  array[i]=0) 

III>    Existential  Quantification 

(Ei :  m  <  i  <  n  :  array[i]«0) 

IV>     Numerical  Quantification 

((Ni  :  m  <  i  <  n  :  array[i]-0)  -  50) 

The  following  are  examples  of  compound  predicates: 

1.  (Cx-y  >  z)  or  (m  -  z)) 

2.  (z  In  [m..n])  imp  (Cz  >  x-y)  and  (z  <  x+y)) 

3.  CCm  -  0)  and  (n  -  10))  and  (Ai :  m  <  i  <  n  :  array[i]-0) 

In  order  to  exercise  the  Prolog  execution  for  the  sample  problem,  a  database 
file  and  several  test  case  files  are  created.  All  the  variables  to  be  used  in  the  test 
file  are  pre-defined  and/or  pre-assigned  constant-values  in  the  database  file.  For 
example,  in  the  database,  a  10-cell  array  byte  has  binary  values  as  00001111, 
and  each  variable  of  x,  y,  and  z  was  bound  with  value  1,  2,  and  3,  respectively. 
Then,  with  the  pre-defined  variables  described  above,  the  following  three 
syntactically-valid  inputs  are  parsed  and  evaluated  (the  value  TRUE/FALSE  is 
the  computed  result): 
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(1)  forall  i:(x..z):byte[i]-0 
TRUE 

(2)  (x>l)or(y>x)andCy<z) 
TRUE 

(3)  (y-x)  and  (byte[y]=0) 
FALSE 


3.4  Programs 

The  source  grammar  (in  BNF  notation)  of  the  Turbo  Prolog  implementation 
is  listed  in  Table  3.1.  The  source  grammar  was  transformed  into  a  Definite 
Clause  Grammar  for  the  C-Prolog  implementation. 

The  following  is  a  list  of  grammars  and  programs  which  are  involved  in  the 
implementation  for  the  sample  problem  described  in  the  previous  section.  A  brief 
description  about  the  functions  of  each  program  is  included  within  the 
parentheses. 
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Grammars 


Source  Grammar  (in  BNF  notation) 
Definite  Clause  Grammar 


Table  3.1 
Appendix  I 


Programs 

C-Prolog: 
Main  Program 
(Main  Control;  Menu  Establishment) 


Appendix  II 


Database  Program 
(Variables/Constants  Assertion  and  Retraction) 

Scanner  Program 
(Lexical  Analysis) 

Parser  Program 
(Parsing,  Evaluation) 


Turbo  Prolog: 
Main  Program 
(Main  Control;  Parsing  and  Evaluation) 


Appendix  in 


Database  Program 
(Variables/Constants  Assertion  and  Retraction) 

Stacks  Program 
(Simulation  of  a  Stack—  Pop/Push  a  value) 

Operators  Program 

(Evaluation  of  Relational/Logical  Expression; 
Determination  of  Precedence  Order  of  the  Logical  Operators) 

Scanner  Program 
(Lexical  Analysis) 
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3.5  Evaluations 

3.5.1   Syntactical  Complexity  Measurement 
3.5.1.1   Rules  for  the  Complexity  Measurement 

For  the  syntactic  complexity  measurement,  Prolog  clauses  can  be  grouped 
into  three  categories: 

RULES:     A  RULE  has  a  complete  clausal  form,  "Head  :-    Tail".    The 
"Head"  is  always  associated  with  an  argument. 

CONTROL  RULES: 

A  CONTROL  RULE  has  the  same  form  as  that  for  a  RULE, 
except  the  "Head"  is  not  associated  with  any  argument.  Since  a 
control  rule  is  invoked  by  calling  its  predicate  name  without 
any  restriction  (or  parameter),  it  is  used  for  the  purpose  of 
control,  e.g.  start :-  opennle(F),  closefile(F). 

FACTS:     A  FACT  consists  of  only  the  left-hand  side  of  a  general  clausal 
form;  that  is,  a  FACT  is  the  "Head"  part  of  a  RULE 

In  Prolog,  a  distinct  predicate  is  a  unique  name  of  the  "Head"  shared  by  one 
or  more  facts/production  rules.  Of  course,  a  goal  is  also  regarded  as  a  distinct 
predicate.  For  instance,  Figure  3.1  shows  two  distinct  predicates.  Predicate 
eetspecialsvmbol  has  a  set  of  four  facts  in  which  each  has  a  different  value  for  its 
argument.  Predicate  const  has  three  production  rules,  where  each  production  rule 
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has  discrete  constituents  for  its  "Tail". 


getspecialsymbol(40,'0). 
getspecialsymbol(41,')'). 
getspecialsymbol(91,'['). 
getspecialsymbol(93,']'). 

a)  Predicate  getspecialsymbol. 


const(num(X),X)  ->  [X],  {numbeKX)}. 
const(varCXXY)  ->  [X],  {vaKX.Yl),  Y-Yl}. 
const(ivar(X),Y)  ->  [X],  {ivar(X,Yl),  Y-Yl). 

b)  Predicate  const 
Figure  3.1:  Distinct  Predicates 

It  is  noted  that  the  syntactical  complexity  (or  the  size)  of  a  predicate  is 
dependent  upon  the  number  of  the  facts,  or  it  is  determined  by  the  number  of  the 
production  rules,  the  type  of  the  component,  the  number  of  occurrences  for  each 
component,  and  the  parameters  used  for  each  occurrence  in  the  "Tail".  Therefore, 
all  of  the  items  described  above  should  be  taken  into  consideration  for  the  com- 
plexity measurement  of  a  program.  Figure  3.2  is  a  list  of  five  major  items  used  in 
the  computation  of  the  complexity  measurement. 
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I)  the  number  of  distinct  predicates. 

II)  the  number  of  production  rules  or  facts. 

III)  the  number  of  called-predicates  in  the  Tail". 

IV)  the  number  of  system  and  I/O  calls  in  the  "Tail". 

V)  the  number  of  parameters  used  in  the  function  calls 

on  the  Tail". 

Notes: 

a)  Tail"  is  the  right-hand  side  of  the  general  clausal  form,  Head  :-  Tail. 

b)  A  "called-predicate"  is  also  a  predicate. 

Figure  3.2:  Determining  factors  for  the  complexity  measurement. 

The  factor  of  item  II  in  Figure  3.2  varies  with  the  categories  to  which  it  applies. 
For  instance,  item  II  is  the  number  of  production  rules  if  applied  to  categories 
RULES  or  CONTROL  RULES,  and  it  is  the  number  of  facts  to  category  FACTS. 
In  addition,  because  the  last  three  items  in  Figure  3.2  are  particularly  involved  in 
the  Tail"  of  a  rule,  they  are  not  applicable  to  the  category  FACTS. 

As  described  in  the  previous  section,  there  exists  some  syntactical  differences, 
especially  the  built-in  predicate  notations,  between  C-Prolog  and  Turbo  Prolog. 
In  order  to  resolve  the  problem  of  notational  difference  and  to  maintain  the  con- 
sistency of  the  measurement,  there  is  a  need  to  standardize  the  counting  unit  of 
each  item  described  in  Figure  3.2.  The  following  are  the  basic  rules  used  to  deter- 
mine the  count  of  system  (I/O)  calls  or  the  number  of  parameters  used  in  a  pro- 
cedure call: 
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(1)  A  built-in  predicate  or  a  system  operator  is  a  system  (I/O)  call,  e.g. 
write,  read,  call,  frontlist,  not,  nl,  fail,  "=", "-..",  and  cut "!". 

(2)  The  special  notations  for  DCG  grammars  in  C-Prolog  are  system  calls, 
such  as "— >", "[]", "{)". 

(3)  A  ";"  is  a  system  call  if  it  is  encountered  in  an  extra  condition;  other- 
wise, it  is  regarded  as  the  control  of  processing  an  alternative  produc- 
tion rule  or  a  fact.  For  instance,  in  the  following  rule  for  parsing  a 
letter, 

is_letter(X)  ->    [X],  (X>64,X<91;  X>96,X<123|. 

if  variable  X  fails  in  the  first  condition-test  for  a  capital  letter,  the  alter- 
native inside  the  "{}"  is  taken,  which  is  a  condition-test  for  a  small  letter, 
rather  than  an  alternative  of  this  production  rule. 

(4)    A  compound  term  expression  or  a  list  expression  is  counted  as  a  singular 
form.  For  instance,  the  expression  "arith_exp" 

arith_exp(multiply(*),3,[5,plus(+),7D 

has  3  parameters.  The  arguments  multiplyW,  3  ,  and  [5,plus(+),7]  are  a 
compound  term,  a  number,  and  a  list,  respectively.  More  illustrations  are 
to  be  given  later  in  the  computation  example. 
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(5)  Anonymous  parameters,  denoted  as  underscore  characters,  appearing  con- 
secutively in  the  right  part  of  an  argument  list  can  be  waived  from  the 
parameter-counting.  For         example,         the         procedure        call 

universal(_jLow,High,_,_)   is   counted  as   three  parameters,   the  first 
underscore  "_,"'  Low,  and  High. 

To  illustrate  the  rules  described  above,  a  small  section  from  C-Prolog 
parser  implementation,  is  given  as  follows: 


(a)  exp([minus.Ll.L2.Val)  —  > 

S. 

const(Ll.Vl),  [■-'],  exp(L2,V2._).  (Val  is  V1+V2). 
P.    A.  A.    SA.     P.   A.  A.        S.A.  S.     A. 

(b)  exp([array.avar(X),ivar(L)],Val)  — > 

S. 

[X].  [•[■].  expCL.Vl.J.  [•]•]. 
S.A.  S.A.    P.  A.A       S.A. 

{avar(X),  Val-V2.  Goal  -..  [X.V1.V2],  call(Goal)}. 
S.P.     A.    A.SA.      A.      S.      A.  S.     A. 


Notes:   The  capital  letters  appearing  under  the  rule  notations 
indicate  the  type  of  count  (or  the  item)  notation  is 
considered.  The  items  the  capitals  represented  are: 

P.  =  Called-Predicate 

S.  —  System/IO  call 

A.  -=  Argument/Parameter 

Figure  3.3:  A  simple  computation  example 
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In  Figure  3.3.  predicate  exp  has  two  production  rules,  (a)  and  (b).  By  applying  rules 
(1)  and  (2),  each  /X]  or  call(Goal)  is  counted  as  a  system  call  associated  with  one 
parameter.  The  system  call  Vol  is  V1+V2  is  considered  as  one  system  call  with  two 
parameters  because  its  operation  sequence  can  be  written  as  is(Val,+(Vl,V2)),  where 
the  +{VJ,V2)  is  a  compound  term.  The  list  IX,Vl,V2j  appeared  in  the  expression  Goal 
=..  [X,Vl,V2l  is  counted  as  one  parameter  according  to  rule  (4).  The  resulting  totals 
for  the  example  above  are  listed  in  Table  3.2. 

Items:      (I)         (II)        (III)        (IV)        (V) 


Rule  (a)  2  4  7 

Rule  (b)  2  8  11 

Total         12  3  11  18 

Table  3.2;  Totals  for  the  example  in  Figure  3.1 
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3.5.1.2  Syntactic  Measurement  for  the  Implementation 

The  functions  of  both  Prolog  programs  include  lexical  analysis,  syntactical 
analysis,  parsing,  and  computation.  Since  the  parser  is  the  major  subject  of 
interest  for  this  report,  and  it  is  easier  to  compare  the  complexities  of  two  pro- 
grams that  function  closely,  both  Prolog  implementations  were  rearranged  into 
two  parts  for  the  complexity  measurement.  They  are  the  scanner  part  the  parser 
part. 

In  C-Prolog,  the  files  "main.p"  (excluding  the  "menu"  function)  and 
"pred^can.p"  are  combined  as  the  scanner  part,  and  the  file  "pred.int.p"  stands 
itself  as  the  parser  part.  For  Turbo  Prolog,  the  parser  includes  the  "parser"  section 
of  the  file  "main.pro"  and  the  file  "operator.inc".  The  rest  of  the  file  "main.pro" 
and  the  file  "scanner.inc"  compose  the  scanner  part.  Since  only  existential 
quantification  was  fully  implemented  in  Turbo  Prolog,  only  existential 
quantification  is  included  in  the  quantification  section  for  both  parsers. 

Tables  3.3  -  3.4  list  the  count  results  of  the  scanner  and  the  parser  for  both 
C-Prolog  and  Turbo  Prolog  implementations. 
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Items  —  > 

Categories 
I 

I 
V 


#  of         #  of  #  of         #  of         #  of 

individ.    produc.  called  system  &    para, 

pred.        rules/  pred  I/O  calls 
facts 


(I) 


(II) 


(III)         (IV) 


(V) 


T.I 

7 

24 

21 

33 

66 

RULES 

C.I 

S 

20 

19 

70[a] 

S7[a] 

CONTROL 

T.I 

1 

1 

5 

3 

7 

RULES 

C.I 

2 

2 

3 

10 

8 

T.I 

0 

0 

- 

- 

- 

FACTS 

C.I 

1 

ll[a] 

tin] 

[a]:      a  discussion  is  made  in  the  context, 
[m]:     """  —  Not  Applicable. 

T.  —  Turbo  Prolog 

C.  —  C-Prolog 

Table  33:  Count  results  for  the  scanner. 


Referring  to  Table  3.3  (the  result  for  the  scanner  part),  it  is  noted  that 
the  C-Prolog  version  has  higher  count  of  system  calls  (item  V).  This  is 
because  C-Prolog  does  not  support  string  I/O  handling  as  Turbo-Prolog  does. 
In  C-Prolog,  each  input  is  fetched  on  the  character-by-character  basis  using 
system  predicates,  such  as  getO,  getOO.  Besides,  the  user  is  required  to  expli- 
citly manipulate  both  the  recognition  of  an  input  character  and  the  type 
conversion  from  characters  to  strings.  Therefore,  both  the  count  of  the  facts 
(item  II)  and  the  count  on  the  parameter-passings  in  category  RULES  (item 
IV)  are  slightly  higher  in  C-Prolog. 
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Items — >  #of  #of  #of         *  of         #  of 

indivld.  produc.  called  system  &    para. 

Categories  pred.  rules/  pred  I/O  calls 

I  facts 


V 

CI) 

(n) 

Cm) 

Civ) 

Cv) 

RULES 

T.I 

C.I 

20 

19 

79 

60 

81 

54 

148 
216[b] 

322 
344 

FACTS 

T.I 

C.I 

1 

0 

4 

0 

- 

- 

Tm] 

[b]:  a  discussion  is  made  in  the  context, 
[m]:  "*■  —  Not  Applicable. 

T.  —  Turbo  Prolog. 

C.  —  C-Prolog. 

Table  3.4:  Count  results  for  the  parser. 


In  Table  3.4,  C-Prolog  has  lower  counts  on  the  Production  Rules  and  the 
Called-Predicates  Citems  II  and  III).  However,  parsing  with  DCG  rule  nota- 
tions invokes  higher  number  of  system  calls  because  most  of  the  rule  nota- 
tions are  the  built-in  functions,  such  as  "□"{ }  etc. 

Section  3.5.1.1  mentions  that  the  syntactical  complexity  of  a  predicate 
is  determined  by  the  number  of  production  rules,  and  the  type,  the  number 
of  the  constituents  in  the  "Tail".  Considering  the  implementation  in  the 
parser  part,  if  the  occurrence  of  both  a  Called-Predicate  and  a  System  Call 
are  given  the  same  complexity  weight,  then  the  syntactical  complexity  of  a 
predicate  can  be  expressed  as  an  equation: 
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(count  of  System  Calls  +  count  of  Called-Predicates) 

(Eq.  1) 

count  of  Production  Rules 


Since  the  number  of  Production  Rules  can  be  varied  by  minor  editing  while 
the  function  of  a  predicate  is  preserved,  the  denominator  of  the  equation 
above  is  replaced  by  the  count  of  the  Predicates. 


(count  of  System  Calls  +  count  of  Called-Predicates) 

(Eq.  2) 

count  of  Predicates 


According  to  Equation  2,   the  calculated  complexity  values  for  both 
parser  are: 


81  +  148 

Turbo  Prolog:     -  11.5 

20 


54  +  216 

C-Prolog: 14.2 

19 


The  results  indicate  that  on  average  C-Prolog  has  a  larger  size  or  a  more 
complex  syntax  per  Predicate  in  the  parser  implementation. 
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3.5.2    Subjective  Evaluation 

This  section  presents  a  different  comparison  of  the  two  Prolog  implementa- 
tions. The  comparison  is  made  and  discussed  in  term  of  the  ease  of  learning  and 
program  development  during  the  course  of  the  implementation  for  this  project. 
Most  of  the  discussions  will  be  focused  on  the  parser  implementation. 

For  a  Prolog  beginner  who  is  familiar  with  conventional  languages  (like  C 
and  Pascal),  Turbo  Prolog  would  be  an  easier  version  for  learning  Prolog  pro- 
gramming. That  is  because  Turbo  Prolog  provides  type-checking  which  helps 
point  out  syntactical  problems.  The  trace  function  is  also  a  plus  feature  to  the 
beginner.  As  the  trace  mode  is  on,  the  cursor  follows  along  from  rule  to  rule  in 
the  editor  window  in  addition  to  the  output  of  the  trace  message.  It  shows 
exactly  how  an  instantiation  occurs  at  every  step  during  searching.  In  addition, 
the  Turbo  Prolog  Owner's  Handbook  [Bor86]  provides  the  user  with  an  excellent 
aide  in  exercising  the  fundamental  programming  skills  in  Prolog. 

C-Prolog,  on  the  contrary,  is  often  frustrating  to  users  during  the  learning 
stage  because  of  its  dynamic  typing  system  and  its  lack  of  proper  documentation. 
Generally,  it  takes  a  user  more  effort  in  learning  C-Prolog  programming,  espe- 
cially the  use  of  DCG  rule  notations  for  parsing.  However,  as  users  become  more 
familiar  with  the  C-Prolog  (DCG)  notations,  they  are  able  to  implement  parsers 
in  a  more  convenient  way. 

Parsing  in  Turbo  Prolog,  on  the  other  hand,  involves  more  user  effort,  such 
as  the  transformation  from  the  source  grammar  to  the  program.    In  order  to 
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achieve  the  same  performance  as  that  in  C-Prolog  parser,  Turbo  Prolog  users  need 
to  define  more  predicates  and  invoke  more  predicate-calls.  However,  if  any  error 
occurs,  the  tracer  does  not  give  adequate  help  in  debugging  in  spite  of  the  user- 
friendly  feature  for  Prolog  beginner  described  earlier.  That  is  because  the  tracer 
does  not  provide  the  depth-level  information  at  each  unification/backtracking 
point  during  searching. 

Let  "implementation-similarity"  be  the  degree  of  closeness  (or  similarity)  in 
syntax  and  structure  of  a  Prolog  parser  to  its  source  grammar.  Higher 
implementation-similarity  of  a  Prolog  program  indicates  the  structure/syntax  of 
the  parser  is  closer  to  its  source  grammar.  It  also  implies  that  it  requires  less 
effort  for  a  Prolog  programmer  to  do  the  program  development. 

Referring  to  C-Prolog  and  Turbo  Prolog  parser  programs  (Appendixes  II,  in) 
and  their  source  grammars  (Table  3.1  and  Appendix  I),  it  is  observed  that  C- 
Prolog  version  has  a  much  higher  implementation-similarity  than  Turbo  Prolog 
does.  In  other  words,  the  C-Prolog  program  preserves  most  of  the  structures  or 
the  syntax  from  its  source  grammar  (DCG).  Because  the  DCG  provides  a 
straightforward,  less  error-prone  technique  for  the  translation,  the  user  is  able  to 
implement  a  program  with  the  features  of  higher  integrity,  readability  and 
correctness. 
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3.6    Conclusions 

C-Prolog  is  consistent  with  the  C&M  Prolog  version.  It  supports  both  the 
DCG  rule  notations  and  dynamic  data  structures.  Turbo  Prolog  provides  a  typing 
system  for  the  compiler  and  supports  several  user-friendly  facilities.  However, 
Turbo  Prolog  does  not  have  built-in  DCG  rule  notations,  and  it  also  lacks  the 
flexibility  in  the  dynamic  creation  of  rule  structures. 

The  syntactical  complexity  measurement  presented  in  Section  3.5.1  draws 
some  interesting  results.  With  the  support  of  string  I/O  manipulations,  Turbo 
Prolog  is  more  advantageous  over  C-Prolog  for  scanner  implementation.  In  the 
C-Prolog  parser,  the  syntactical  structure  of  each  production  rule  has  a  slightly 
higher  complexity  despite  the  use  of  DCG  rule  notations. 

Programmers  may  feel  more  comfortable  in  Turbo  Prolog  programming  dur- 
ing the  earlier  stage  (learning  stage)  because  of  Turbo  Prolog's  user-friendly  facil- 
ities and  good  tutorial  reference.  However,  C-Prolog  has  much  higher 
implementation-similarity,  which  indicates  the  higher  similarity  between  of  a  C- 
Prolog  program  and  its  source  grammar.  Because  Prolog  implementation  using 
DCG  requires  less  program  development  in  the  transformation,  users  can  write  a 
parser  program  with  higher  integrity,  readibility,  and  correctness. 

To  conclude,  DCG  provides  a  good  tool  for  parsing  in  Prolog.  From  the 
aspect  of  implementation  design,  the  use  of  DCG  for  Prolog  parsing  is  desirable 
despite  the  possibility  of  higher  syntactical  complexity. 

To  provide  other  users  documentation  about  the  use  of  a  DCG  for  parsing  in 
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Prolog,  a  BNF  defining  the  structure  of  a  DCG  is  listed  in  Appendix  II.   In  addi- 
tion, the  examples  of  Section  2.3  serve  as  a  tutorial  reference. 
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Appendix  I:      Grammars 


Context  Free  Grammar 


Interp  —  >     Pred  MorePred 

Morepred  —  >     Lop  Pred   Morepred 
Morepred  —  >     null 

Pred    ->     "("  Quant  ")" 
Pred     —  >     LexpO 

Quant    —  >     "forall"   Quantbody 

Quant    —  >     "therexist"  Quantbody 

Quant    —  >     "("   "numberof"  Quantbody  ")"  "-"  Const 

Quantbody—  >    Var  ":"  "("  Ivar  ".."  Ivar  ")"  ":" 
Avar  "["  Var  "]"  Relop  Const 

LexpO    —  >     "("  LexpO  ")" 
LexpO    —  >     Lexpl   LexpOmore 

Lexpl    —  >     "("   Lexpl   ")" 
Lexpl    —  >     Lexp2  Lexplmore 

Lexp2    —  >     "("  Lexp2  ")" 
Lexp2    —  >     Lexp3  Lexp2more 

Lexp3    —  >     "("  Lexp3   ")" 
Lexp3    —  >     Lexp4   Lexp3more 

Lexp4    —  >     "("   Lexp4  ")" 
Lexp4    —  >     Rexp  Lexp4more 

LexpOmore  —  >     "eqv"  LexpO 
LexpOmore  —  >     null 

Lexplmore  —  >     "imp"  Lexpl 
Lexplmore  —  >     null 

Lexp2more  —>     "xor"   Lexp2 
Lexp2more  —  >     null 
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Lexp3more  —  >     "or"    Lexp3 
Lexp3more  —  >     null 

Lexp4more   —  >     "and"   Lexp4 
Lexp4more  —  >     null 

Rexp  —  >  "not"  Rexp 
Rexp     —  >     Exp  Relop  Exp 

Exp       —  >     Const  Constmore 
Exp       —  >     Avar  "["   Exp  "]" 

Constmore  —  >  "+"  Exp 
Constmore  —  >  "-"  Exp 
Constmore  — >     null 

Relop    — >     V  | ">"  |  "<"!"<>"  I  ">-"|"<. 
Lop       —  >     "and"  I  "or"  I  "xor"  I  "imp"  I  "eqv" 

Const    —  >     int  (any  legal  integer} 
Const    —  >     Var 

Ivar     —  >     ivar  (any  defined  index  variable) 

Var      —  >     var  (any  defined  variable) 

Avar     —  >     avar  (any  defined  array  variable) 
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Definite  Clause  Grammars 


interp(L.Val)->    pred(Ll,Vl).  morepred(L2,V2,Op). 
{  L2-[],  L-Ll.  Val-Vl: 
L-lexp(0p.Ll.L2).  Val-VKOp>V2   }. 

morepred(L.Val.Op) ->    [].  {L-[]l- 

morepred(L.Val.Op)  — >    lop(Lop).  pred(Ll.Vl).  morepred(L2,V2,Opl), 
{  L2=[],  Op-Lop.  L-Ll,  Val-Vl: 
L-lexp(Opl.Ll,L2),  Val-VKOpl>V2,  Op=Lop 

pred(L.Val) ->    [(],  quant(L.Val).   [)]. 
pred(L,Val)->    lexpO(L.Val). 


lexpO(L,Val)  ->  [(].   lexpO(L.Val),  [)]. 

lexpO(L.Val)  — >  lexpl(Ll.Vl).   lexpmore(eqv,Ll.Vl.L.Val). 

lexpl(L.Val) ->  [(],  lexpl(L.Val).  [)]. 

lexpl(L.Val)  ->  lexp2(Ll.Vl).  lexpmore(imp,Ll,Vl.L.Val). 

lexp2(L,Val) ->  [(].  lexp2(L,Val).  [)]. 

lexp2(L.Val)  ->  lexp3(Ll,Vl),  lexpmore(xor.Ll.Vl.L.Val). 

lexp3(L.Val) ->  [(],  lexp3(L.Val),  [)]. 

lexp3(L.Val) ->  lexp4(Ll.Vl).  lexpmore(or.Ll.Vl.L.Val). 

lexp4(L.Val) ->  [(].   lexp4(L.Val).  [)]. 

lexp4(L.Val)  ->  rexp(Ll.Vl).   lexpmoreCand.Ll.Vl.L.Val). 


lexpmore(eqv.Ll.Vl.L.Val)  ->     [eqv],  lexpO(L2.V2). 

{  Val-  evaluated  result  from  "VI  'eqv'  V2". 
L-lexp([eqv.Ll.L2])     }. 
lexpmore(imp.Ll.Vl.L.Val)  — >     [imp],  expl(L2.V2). 

{  Val-  evaluated  result  from  "VI  'imp'  V2", 
L=lexp([imp.Ll,L2])    }. 
lexpmore(xor.Ll,Vl.L.Val)  ->     [xor],  lexp2(L2.V2). 

(  Val-  evaluated  result  from  "VI  'xor'  V2". 
L=lexp([xor.Ll.L2])     ). 
lexpmore(or.Ll.Vl.L.Val)  ->     [or].   lexp3(L2,V2). 

{  Val-  evaluated  result  from  "VI  'or'  V2". 
L-lexp([or.Ll.L2])      ). 
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lexpmore(and.Ll.Vl.L.Val)->     [and],   lexp4(L2,V2), 

{  Val-  evaluated  result  from  "VI  'and'  V2", 
L=lexp([and,Ll,L2])    }. 
lexpmore(Lop.Ll.Vl.Lf.Vf)  ->     [], 

{  Lop-"any  defined  logical  operator".  Lf-Ll,  Vf-Vl 


quant(L,Val)->    [forall],  quantbody(Ll.Val).   {  L=forall(Ll)  ). 
quant(L.Val)  —  >    [therexist].  quantbody(Ll.Val).   (  L=therexist(L)  ). 
quant(L.Val)  ->    [Q,   [numberof],   quantbody(Ll.Val).   [)],   [-].   const. 

quantbody— >     var.  [:],  [(].  ivar.  [..].  ivar.  [)],  [:]. 
avar,  ['['],  var,  [']'].  relop,  const. 


rexp(L.Val)  ->    [not].  rexp(Ll.Vl).   {  Val-  negation  of  value  VI,  L=not(Ll)  ). 
rexp(L.Val) ->    exp(Ll.Vl),  relop(Rop).  exp(L2.V2). 

(  Val=  evaluated  result  from  "VI  Rop  V2", 
L=rexp([Rop.Ll.L2])    }. 

exp(L.Val)  — >    const(Ll.Vl).  moreconst(L2,V2,Op). 
I  Val-  "VI  Op  V2".  L-[Op.Ll.L2]       ). 
exp(L.Val)  ->    [Avar],   ['['].  exp(Ivar.Vl).  [']']. 
{  Va-  the  attribute  of  "Avar[Vl]\ 
L=[array,avar(Avar).ivar(Ivar)]    }. 


relop(>-)  ->    [>].  [-]. 
relop(<-)  ->    [<].  [-1 
relop(<>)  ->    [<].  [>]. 
relop(-)  ->    [-]. 
relop(<)  — >    [<]. 
relop(>)  ->    [>]. 


lop(and)  —  >     [and]. 

lop(or)    —  >  [or]. 

lop(xor)  —  >  [xor]. 
lop(imp)   —  >     [imp]. 

lop(eqv)  —  >  [eqv]. 
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moreconst([].0.[])    — >    [] 
moreconst(L.Val,V)  —  >    [+]  exp(L.Val) 
moreconst(L,Val,'-')  —  >    [-]  exp(L.Val) 

const(num(X))  —  >    [X],   I  X  is  a  legal  integer  ). 
const(var(X))  ->    [X],   {  X  —  the  attribute  of  val(X)  ). 
const(ivar(X))  —  >    [X],   {  X  —  any  ivar(X)  defined  in  the  database  ] 
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Appendix  Hi  C-Prolog  Implementations 


********** 


% 

%  "main. pro" 

%  ********** 

% 

7o  This  program  performs  the  following  functions: 

%         the  files  consultation,  the  creation/control  of  menu, 

%         the  linkage  to  scanner  and  parser  programs,  and 

%         the  output  of  the  results. 

% 


-    consult('pred.scan.pro'). 
consult('pred.parse.pro'), 
consult('pred.db.pro'). 
assertdb, 
nl,  menu. 


menu  :-    writeC  \\\\\\\\  MENU  ////////  -),  nl. 

writeC ').  nl. 

writeC    a)   simple  predicate.  ').  nl, 

writeC     b)   predicate  with  universal  quantification.       ').  nl. 
writeC    c)   predicate  with  existential  quantification.     ').  nl. 
writeC    d)  predicate  with  numerical  quantification.       ').  nl. 
writeC    o)  user  input.i  ').  nl. 

writeC    q)   quit  from  the  program.  ').  nl. 

writeC  Please  enter  the  code,  then  hit  <cr>  ').  nl. 

get(Code).  getO(_). 
testfile(Code.Repeat). 
Repeat=true,  menu,  nl. 


testfile(C.true) 
testfile(C.true) 
testfile(C.true) 
testfile(C.true) 
testfile(C.false) 
testfile(C.true) 


C-97,  startCtest.simple.pred'. user). 

-  C-98.  startCtest.qall'.user). 
C=99.  startCtest.qexist'.user). 
C-100,  startCtest.qnum'.user). 

-  Oil 3,  retractdb.  !. 

-  C-lll. 

writeCplease  enter  the  file  name,  followed  by  '). 
writeCa  dot  and  <cr>.   '),  nl, 
read(File),  nl,  start(File.user). 
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testfile(_.Val)    :-     nl, 

writeCPlease  re-enter  the  code,  then  hit  <cr>  '), 

nl.  get(Code),  getO(_), 

testfile(Code.Val). 

start(Infile.  Outfile)  :- 

see(Infile), 

tell(Outfile). 

writeC  Input  tokens  ').  nl. 

writeC ').  nl, 

getO(Ch), 

scan(Ch.Wordslist) , 

seen,  nl,  nl, 

writeC  Parsing/Evaluation  ').  nl, 

writeC ').  nl, 

interpret(Parselist.Val.Wordslist), 

write(Parselist).  nl. 

writeC  **  the  result  — >  '), 

write(Val),  nl,  nl,  nl, 

told. 
start(_,_)  :-  seen.  told. 
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Jc    ************* 

%  "pred.db.pro" 
tf0  ************* 

% 

%  The  information  stored  in  this  database  includes: 

%  integer  variables  (ivar) 

%  m  -  0,  n  -  3, 

%  x  -  1.  y  -  3.  z  -  5. 

%  a  -  10,  b  -  20,  c  -  30. 

% 

%  array  variables  (avar) 

%  byte  -  "00001111" 

%  count-  "0123456789" 

% 

assertdb  :-  db,  valdb,  bindb,  countdb,  ivardb. 

retractdb  :-  db,  valout,  binout.  countout. 
retractdb  :-  nl, 

writeC  **  empty  database  **  '). 

nl. 


db  :-  assert(avar(byte)).  assert(avar(count)). 

ivardb  :-  assert(ivar(m,0)),  assert(ivar(n,3)). 
ivarout :-  retract(ivar(_,_J).  ivarout. 
ivarout. 

valdb  :-  assert(val(x.l)).  assert(val(y,3)),  assert(val(z,5)), 
assert(val(a,10)),  assert(val(b,20)).  assert(val(c,30)). 
valout :-  retract(val(_._)).  valout. 
valout. 


%     Arrays 
% 

bindb  :- 
assert(byte(0,l)),  assert(byte(l,l)).  assert(byte(2,l)). 
assert(byte(3,l)),  assert(byte(4,0)).  assert(byte(5,0)). 
assert(byte(6,0)).  assert(byte(7.0)). 

binout :-  retract(byte(_,_)),  valout. 
binout. 
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countdb  :- 
assert(count(0,0)),  assert(count(l,l)).  assert(count(2.2)), 
assert(count(3,3)),  assert(count(4.4)),  assert(count(5,5)), 
assert(count(6,6)).  assert(count(7.7)).  assert(count(8,8)). 
assert(count(9.9)). 

countout  :-  retract(count(_,_)),  countout. 
countout. 
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%  *************** 
%  "pred.scan.pro" 
% 

% 


*************** 


%  This  program  performs  the  lexical  analysis  of 
%  the  input. 


scan(26.[])  :-  !.       %  "Z"  — >  end  of  input 
scan(32.TokenList)  :- 
getO(Ch),  !, 

scan(Ch  .TokenList). 
scan(lO.TokenList)  :- 
getO(Ch), !. 

scan(Ch.TokenList). 
scan(Ch.[WdlTokenList])  :- 

getspecialsymbol(Ch.Wd). 

write(Wd),  tab(l), 

getO(Chl), !, 

scan(Chl. TokenList). 
scan(Ch,[WdlTokenList])  :-  %  get  a  word  or  a  number 

getword(Ch,Wdl  .LastCh). 

name(Wd,Wdl). 

write(Wd).  tab(l). !. 

scan(LastCh.TokenList). 
scan(Ch.[WdlTokenList])  :- 

name(Wd.[Ch]).  nl. 

writeCWd). 

writeC  <>-»**  invalid  token  **'). 

nl.  nl. 

!.  fail. 


getword(Ch.[ChlWdl].LastCh)  :- 

letter(Ch). !. 

getO(Chl), 

isnameCChl  .Wdl  .LastCh). 
getword(Ch.[ChlWdl].LastCh)  :- 

digit(Ch), !, 

getO(Chl). 

isnumber(Ch  1  ,Wd  1  .LastCh). 
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isname(Ch.[ChlWd].LastCh)  :- 

letter(Ch). !. 

getO(Chl),  isname(Chl,Wd.LastCh). 
isname(Ch.[ChlWd].LastCh)  :- 

digit(Ch). !. 

getO(Chl).  isname(Chl.Wd.LastCh). 
isname(Ch,[],LastCh)  :- 

LastCh-Ch. 


isnumber(Ch.[ChlWd].LastCh)  :- 

digit(Ch).  !. 

getO(Chl).  isnumberCChl.Wd.LastCh). 
isnumber(Ch,[].LastCh)  :- 

LastCh-Ch. 


letter(Ch)  :-  Ch>64,  Ch<91:  %  capital 

Ch>96,  Ch<123.         %  small  letter 


digit(Ch)  :-  Ch>47.  Ch<58. 


%  Operaters 

getspecialsymbol(40.'(')- 

getspecialsymbol(41.')'). 

getspecialsymbol(61,'«')- 

getspecialsymbol(91.'['). 

getspecialsymbol(93.']')- 

getspecialsymbol(60.'  < '). 

getspecialsymbol(62.'  > '). 

getspecialsymbolC46,'.'). 

getspecialsymbol(58.':'). 

getspecialsymbol(43.'+')- 

getspecialsymbol(45,'-')- 

%    print  facility 
% 


writeall([])  :-  nl.  nl.  I. 
writeall([XIXl])  :- 

writeC").  write(X),  writeC"). 

tab(2).  writeall(Xl). 
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J0  **************** 

%  "pred.parse.pro" 

of0  **************** 

% 

%  This  program  performs  the  functions  of  parsing  and  execution. 

% . 

%  The  precedence  of  the  logic  operators  is  and>  or>  xor>  imp>  eqv, 

%  and  it  has  been  implemented  into  the  source  grammar.  However, 

%  it  is  recommended  that  user  always  use  parantheses  for  input 

%  expression. 

% 

%  All  the  quantification  SHOULD  BE  PARENTHESIZED. 

%         For  example: 

%  (therexist  i:(j..k):count[i]«4) 

%  (forall     i:(j..k):byte[i]=0) 

%  ((numberof  i:(j..k):byte[i]-l)-4) 

% 


interpret(ParseList.Val.TokenList)  :-    interp(ParseList.Val.TokenList,[]). 
interpret(ParseList.Val.TokenList)  :-    told,  !,  fail. 


%  ********************************************* 

%  Parsing  with  the  Definite  Clause  Grammar  Rule 

% 


interp(L.Val)  — >     pred(Ll.Vl),  morepred(L2,V2,Op). 
(  L2-[].  L-Ll.  Val-Vl; 
L-lexp([Op,Ll.L2]).  Val-V,  evallog(V,Vl.V2.0p) 

pred(L.Val)  ->     [•("].  quant(L.Val),  [Jl 
pred(L.Val)  ->     lexpO(L.Val). 


morepred(L,_,_)   ->     [].  {L-[]l- 
morepred(L.Val.Op)  —  > 

lop(Op).  pred(Ll.Vl).  morepred(L2,V2.0pl). 

(  L2-[],  L-Ll.  Val-Vl; 
L=lexp([Opl,Ll.L2]),  evallog(V.Vl.V2.0pl).  Val=V  ). 
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quant(forall(Rel.A,C).Val)  -> 

[forall],  quant.body(Avar,Idl,Id2.Rel.C). 
{universal(Avar,Idl,Id2,Rel,C.V). 
Val-V.  A-..[Avar.Idl.Id2]  ). 

quant(therexist(RelA,C),Val)  —  > 

[therexist],  quantbody(Avar.Idl,Id2,Rel,C), 
(  exist(  Avar Jd  1  ,Id2  .Rel.C.V). 
Val-V,  A-..[Avar.Idl.Id2]        ). 
quant(numberof  (-.[Rel,A.C],Count).Val)   —  > 

['(■].  [numberof],  quantbody(Avar,Idl.Id2.Rel.C).  [01 
['-'].  const(_.Count). 
(  numerical(Avar.Idl,Id2,Rel,C,0,Cnum), 
Cnum-Count,  Val-true,  A-=..[Avar,Idl.Id2]. !; 
Val-false  }. 


quantbody(Avar,Idl,Id2.Relop  .Const)   — > 

[XI].  [•:•].[•(•].  [II],  [•.•].[•••].  [12].  m.  I-:! 

[Av],  [■[■].  [X2].  [•]•],  relop(Relop).  const(_.Const). 

{  X1-X2,  avar(Av),  Avar-Av. 

const(^Jl.[Il].[]). 

C0nstO2.[l2].[]). 

JKJ2.  Idl-Jl,  Id2-J2  }. 


lexpO(L.Val)  ->  [X'l  lexpO(L.Val).  [')']. 

lexpO(L.Val)  ->  lexpl(Ll.Vl).  lexpmoreCeqv.Ll.Vl.L.Val). 

lexpl(L.Val)  ->  [■('].  leipl(L.Val).  [')■]. 

lexpl(L.Val)  ->  lexp2(Ll.Vl),  lexpmore(imp,Ll.Vl,L.Val). 

lexp2(L,Val)  ->  [•('].  lexp2(L.Val).  [01 

lexp2(L,Val)  ->  lexp3(Ll.Vl).  lexpmore(xorXl.VlX.Val). 

lexp3(L.Val)  ->  [VI  lexp3(L.Val).  [01 

lexp3(L,Val)  ->  lexp4(Ll.Vl).  lexpmore(orXl,VlX,Val). 

lexp4(L.Val)  ->  ["(1  lexp4(L,Val).  [01 

lexp4(L.Val)  ->  rexp(Ll.Vl),  lexpmore(andXl.VlX.Val). 
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lexpmore(eqv,Ll.Vl,Lf.Vf)  -> 

[eqvL  lexpO(L2.V2). 

{  evallog(V.Vl,V2.eqv),  Vf-V,  Lf=lexp([eqv.Ll.L2])  ). 
lexpmore(imp.Ll.Vl.Lf.Vf)  -> 

[imp].  lexpl(L2.V2). 

(  evallog(V,Vl.V2.imp),  Vf-V.  Lf-lexp([imp,Ll.L2])  }. 
lexpmore(xor.Ll.Vl.Lf,Vf)  -> 

[xor].  lexp2(L2.V2). 

{  evallog(V,Vl.V2,xor).  Vf-V.Lf-lexp([xor.Ll.L2])  ). 
lexpmore(or,Ll,Vl,Lf,Vf)  -> 

[or],  lexp3(L2,V2), 

(  evallog(V.Vl.V2.or).  Vf-V,  Lf-lexp([or.Ll,L2])  ). 
lexpmore(and.Ll.Vl.Lf,Vf)  -> 

[and],  lexp4(L2.V2). 

{  evallog(V.Vl,V2.and).  Vf-V.  Lf=lexp([and,Ll.L2])  }. 
lexpmore(_ll.Vl.Lf.Vf)  ->     [].  (  Lf-Ll.  Vf-Vl   }. 


rexp(not(L).Val)  —  > 

[not].  rexp(L.V).  {  Val-true.  V-false;  Val-false   ]. 
rexp(rexp([Op.Ll,L2]),Val)  —  > 

exp(Ll.Vl).  relop(Op).  exp(L2.V2). 

{  Val-V.  evalrel(V.Vl.V2.0p)   }. 


exp(L.Val)   — >     const(L.Val). 
expdplus.  Ll.L2].Val)  -> 

const(Ll.Vl).  [■+■].  exp(L2.V2).  {  Val  is  V1+V2   }. 
exp([minus.Ll.L2].Val)  —  > 

const(Ll.Vl).  [•-•].  exp(L2.V2).  {  Val  is  V1-V2  ). 
exp([array.avaKX),ivar(L)],Val)  — > 

[X].  [•[■].  exp(L.Vl).  [•]■]. 

{  avar(X).  Val-V2.  Goal  -..   [X.V1.V2],  call(Goal) 


relopO-')   ->     [•>■].[■-■]. 
relopO  <>')   ->     [•<■].[•>"]. 
relopC<-)  ->     [•<•],[■-']. 
relopO')  — >     [■>"]. 
relopC-0  ->     [•-■]. 
relopCO  ->     [■<•]. 


-60- 


lop('and')  — >     [and]. 

lop('or')    — >  [or]  . 

lop('xor')  —  >  [xor]. 
lop('imp')   — >     [imp]. 
lop('eqv')  — >     [eqv]. 


constC  num(X).X)   ->     [X].  (number(X)). 
constC  var(X).Y)  ->     [X],  (val(X.Yl).  Y=Y1). 
const(ivar(X).Y)   ->     [X].  {ivar(X.Yl),  Y=Yl). 


CfQ  ******************************************************** 

%  The  following  predicates  are  the  user-defined  functions. 

%  Each  predicate  is  invoked  by  a  procedure  call  from  the 

%  extra  condition  (semantic  actions)  in  the  rules  above. 

OfQ  ******************************************************** 


%    Evaluation  of  the  values  specified  in  quantifications 
%    _ 

universal(_.Low,High,_._,true)  :-  Low  >  High. 
universal(Avar,Low.High,Op,Const.Val)   :- 

Goall   •=..  [Avar,Low,Num],  call(Goall). 

Goal2   -..  [evalrel,V2.Num.Const.Op],  call(Goal2), 

V2=true.  Next  is  Low  +  1, 

universal(Avar,Next.High,Op.Const,Val). 
universal(_,_,_,_,_,false). 


exist(_iow,High,_,_,false)  :-  Low  >  High. 
exist(Avar.Low,High,Op,Const.Val)   :- 

Goall   =..   [Avar.Low.Num],  call(Goall). 

Goal2  -..   [evalrel.V2.Num,Const,Op],  call(Goal2). 

V2=false.  Next  is  Low  +  1. 

exist(Avar.Next.High,Op.Const.Val). 
exist  (_,_,_._,_,true). 
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numericaK Xow.High, , .Count.Count)  :-    Low  >  High. 

numerical(Avar,Low,High,Op,Const.Count,Total)   :- 
Goall   -..   [Avar,Low.Num],  call(Goall), 
Goal2   -..   [evalrel.V2.Num,Const.Op],  call(Goal2). 
V2=true,  Cnum  is  Count  +  1,  Next  is  Low  +  1, 
numerical(Avar,Next,High,Op.Const,Cnum,Total). 

numerical(Avar,Low,High,Op,Const,Count.Total)   :- 
Next  is  Low  +  1, 
numerical(Avar,Next,High.Op,Const,Count,Total). 


%    Evaluation  of  a  logical  expression 

%    Note:  (VI  imp  V2)  —  (not(Vl)  or  V2) 

% 


evallog(true.Vl.V2.and)   :-    V1-V2.  Vl-true. !. 
evallog(true.Vl.V2.or  )   :-    not«Vl«V2.Vl=false)).  I. 
evallog(true.Vl.V2.xor)  :-    not(Vl-V2). !. 
evallog(true.Vl,V2,imp)   :-    not((Vl«true.V2«false)), !. 
evallog(true,Vl.V2.eqv)   :-    V1-V2.  !. 
evallog(false.Vl.V2,Op). 


%    evaluation  or  a  relational  expression 
% 

evalrel(true,X.Y,'>')    :-    X>Y, !. 
evalreKtnie.X.Y.'--)    :-    X-Y, !. 
evalreKtrue.X.Y.'-O    :-    X<Y. !. 
evalreKtrue.X.Y.'O')  :-    X— Y. !. 
evalrel(true.X,Y,,<--)   :-    X-<Y. !. 
evalreKtnie.X.Y,' >«')   :-    X>-Y.  !. 
evalrel(false.X,Y.Op). 
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Appendix  III:       Turbo  Prolog  implementations 


I* 
I* 

/♦ 
f* 

/* 
/« 


mam. pro 


This  program  covers  the  functions  of 
main  control  and  parsing/execution 


*/ 

*/ 
*/ 
V 
*/ 

*/ 


code-2048 

domains 
tok  -  int(integer);  opl(char);  op(string);  name(string) 
tokl  -  tok* 
values  -  symbol* 


database 
valCstring,  integer) 
avar(string) 
ivar(string.integer) 
array(string.integer  .integer) 


/*  variable  */ 
/*  array  variable  */ 
/*  index  variable  */ 
/*  social  security  no.  */ 


valdb(  values) 

lopdb(tokl) 

preddb(string.integer) 


/*  stack  for  boolean  values  */ 
/*  stack  for  logical  operators  */ 
/*  for  debugging  use  */ 


include  "database. inc" 
include  "stacks. inc" 
include  "scanner.inc" 
include  "operators.inc" 


predicates 
start 

writeln(string) 
pred(tokl.symbol.tokl) 
lexp(tokl,symbol,tokl) 
sexp(tokl,tokl,tokl,integer) 

check(tokl) 
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morelexp(tokl.tokl) 
openp(tok) 

negate(symbol.symbol) 

evalop(tok) 

fineval(symbol.symbol) 

rangeGnteger  .integer  .integer.symbol) 

f  rontlistCtokl  .tok.tokl) 

quant(symbol,string.integer,integer,integer, 

integer  ,symbol.integer,integer.integer) 

typeval(sy  mbo  1) 
writeval(tok,symbol,symbol.symbol) 


goal 

start. 


clauses 

writeln(X)   :-  write(X),  nl. 

I*  main  control  and  utilities  */ 
start   :- 

writelnCsimple  predicate  interpreter"), 

writeln("enter  expression"). 

readln(Str).nl.  !. 

scan(Str.Tokl). 

init. 

check(Tokl). 

reinit. 

writeln("done"). 


check(Tokl)   :- 

pred(Tokl,V.[]),  nl.  write("result  =  "), 
typeval(V),  writeln("***  pass  check  ***").  !. 

check(_)   :-  nl.  writeln("**»  fail  pass  ***"). 
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/*  more  printer  facilities 


typeval(true)  :-  writelnCtrue").  !. 
typeval(_)   :-  writelnCfalse"). 


writeval(op("and"),Vl,V2.Vf)  :- 

write(Vl),  write("  <and>  "),  write(V2), 

write("  —  >  "),  write(Vf),  nl. 
writeval(op(Lop).Vl.V2,Vf)  :- 

write(Vl),write("  <").write(Lop),write(">  "). 

write(V2).write("  =>  "),write(Vf),nl.  !. 


/*        parser 

»/ 

pred([op("therexist")ITokl].Vpred,Tok)   :- 

frontlist(Tokl,name(Indx),[opl(':')ITok2]). 
frontlist(Tok2,opl(T).[name(Xl)ITok3]). 
ivar(Xl.Vl). 

frontlist(Tok3,op(".."),[name(X2)ITok4]). 
ivar(X2,V2), 
V2>V1. 

frontlist(Tok4,oplC]').[oplC:')ITok5]), 
frontlist(Tok5.name(Avar).[opl('[')ITok6]). 
avar(Avar). 

frontlist(Tok6,name(Indx),[opl(']')ITok7]). 
frontlist(Tok7.opl('-').Tok8). 
sexp(Tok8,_^Tok.Dato), 

quant(therexist.Avar,Vl,V2,_,Data.Vpred,_._._), 
!. 
pred(Tokl,Vprops.Tok2)   :- 

lexp(Tokl,Vlexp,Retoks). 

pushval(Vlexp), 

morelexp(  Retoks,Tok2) , 

popval(V2), 

fineval(V2,Vprops),   !. 
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quant(therexist.A.L._,^Data.true._,_._)    :- 

array(AJ-.Data).   !. 
quant(therexistA,L.H.Next,Data.Val._,_,N)   :- 

Next-L+1. 

H  >«Next. 

quant(therexistA,Next.H.N,Data,Val._._,_), 
quant(therexist._._,_,_,_,false,^_J_)   :-    !. 


morelexp([],[])  :-    I. 
morelexp([opl(T)IRl].[opl(T)IR2])   :- 

T-')'.   I.R2-R1,  !. 
morelexp([TflTt].Tok2)   :- 

lop(Tf),  pushlop(Tf). 

lexp(Tt.V.Retoks),   !. 

pushval(V), 

poplop(Op), 

evalop(Op). 

morelexp(Retoks.Tok2),   !. 


lexp([opl(T)IRetokl].V.Retok2)   :- 
T--C. 

pushlop(opl  (T)) , 
pred(Retokl.V,[opl(Tl)IRetok2]). 
Tl-  ')'. 
poplopU,   !. 
lexp([op(T)IRetokl].V.Retok2)  :- 
T-"not". 
pushlop(op(T)), 
lexp(Retokl  ,V1  ,Retok2). 
negate(V.Vl). 
poplop(opCT)).  !. 
lexp([name(X)IT].Val.Rtoks)   :- 
ivar(X.V),   !. 

frontlist(T.op("in").[oplC[,)ITl]). 
frontlist(Tl.name(Xl).[op("..")IT2]). 
ivar(Xl.Vl),   !, 

frontlist(T2.name(X2),[oplC]')IRtoks]), 
ivar(X2.V2),   !. 
range(V.Vl,V2.Val).   I. 
lexp(T,Val.Rtoks)   :- 

sexp(T,_,[TllT2],Vl),   !, 
relop(Tl), 

sexp(T2.JUoks,V2). 
evalrop(Tl.Vl.V2,Val).   !. 
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evalop(opCnot"))   :- 

popval(V), 

negate(Vf.V). 

pushval(Vf).  !. 
evalopCopCand"))   :- 

popval(V),  popval(Vl). 

evallop(op("and").Vl  .V.Vf ). 

writeval(op("and").Vl.V.Vf). 

pushval(Vf),  I. 
evalop(L2)   :- 

poplop(Ll), 

preced(L2.Ll),   !. 

popval(V).  popval(V2).  popval(Vl). 

evallop(Ll.Vl.V2.Vfinal). 

writeval(Ll.Vl.V2.Vfinal). 

pushval(Vfinal),  pushval(V), 

evalop(L2).   !. 
evalop(L2)   :- 

pushlop(L2).    !. 


fineval(V2.Val)  :- 

poplop(Lop). 

pushlop(Lop). 

openp(Lop).  !. 

Val-V2. 
fineval(V2.Val)  :- 

popval(Vl),  poplop(Lop). 

evallop(Lop.Vl,V2.Vf). 

writeval(Lop.Vl.V2.Vf). 

fineval(Vf.Val).   !. 
fineval(V2,V2)   :-    !. 


sexp([name(X)IT2].T2.T2.V)    :-  val(X.V).   !. 
sexp([name(X)IT2].T2.Tf.V)    :- 
avar(X).   !. 

seip(T2,_.Tf.Vl). 
array(X.Vl.V).   !. 
sexp([int(N)IT2].T2.T2,V)      :-  V  -  N.  !. 
sexp([opl(T)IT2].T2.Tf,V)  :- 

sexp(T2.[oplO]")rTf]._JV).   !. 
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negate(Vn,true)  :-    !,  Vn-false. 
negate(Vn,_)       :-  Vn=true,   !. 


frontlist([THT2].Tl.T2)   :-    I. 


range(N,Nl.N2,true)  :- 

N  >-Nl.  N  <-N2.  !. 
range( , , .false)   :-    !. 


openp(opKT))   :-  T-"C.   !■ 
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/*         "database.inc"         */ 

/*     , __.       «/ 


predicates 
init 
reinit 
ssninit 


clauses 

init  :- 

assert(ivarCone",l)),  assert(ivar{"two".2)), 
assert(ivar("three",3)).  assert(ivar("four",4)), 
assert(ivaK"five",5)),  assert(ivar("six",6)). 
assert(ivaK"seven",7)).  assert(ivar("eight\8)). 
assert(ivar("nine",9)),   assert(ivaK"ten",10)), 
assert(ivar("eleven".ll)),  assert(ivar("twelve".12)), 
assert(ivar(" thirteen",  13)).  assert(ivar("fourteen",14)), 
assert(ivaK"fifteen",15)). 

assert(avar("ssn")) . 

assert(arrayCssn".l,5)).  assert(array("ssn".2.1)), 

assert(array("ssn",3,5)).  assert(array("ssn".4,8)), 

assert(array("ssn".5,2)).  assert(array("ssn",6.8)), 

assert(array("ssn".7,4)),  assert(array("ssn".8,0)), 

assert(array("ssn".9,3)). 


rt(val(V.3)),  assert(val("y".2)).  assert(val("z",l)), 
assert(valdb([])),  assert(lopdb([])), 
assert(preddb("props  ",0)).  assert(preddb("molexp".0)), 
assert(preddb("lexp  ",0)),  assert(preddb("evalop",0)). 


reinit   :- 

retract(valCY._)),  retract(val("y"._)).   retract(val(V._)), 
retract(valdb(_)),  retract(lopdb(_)) . 
retract(preddb("props  "._)),  retract(preddb("molexp"._)). 
retractCpreddbClexp  ",_)),  retract(preddb("evalop",_)), 
ssninit. 
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reinit  :- 

retract(val(V,_)),  retract(val("y",_)).   retract(val("z",_)). 

retract(valdb(_)).   retract(lopdb(_)). 

retractfpreddb  ("props  "._)).  retract(preddb("molexp",_J), 

retract(preddb("lexp  "._)).  retract(preddb("evalop",_)), 

ssninit. 


ssninit  :- 

retract(array("ssn",l._)),  retract(array("ssn".2,_)), 

retract(array("ssn",3,_)),  retract(array("ssn",4._M, 

retract(arrayCssn",5,_)),  retract(array("ssn",6,_)), 

retract(array("ssn",7,_)),  retract(array("ssn",8,_)), 
retract(array  ("ssn".9 ,_)) . 
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/*  stacks.inc 


This  programs  performs  the  function  of  a  stack 
_ V 


predicates 

pushval(symbol) 
popval(symbol) 
pushlop(tok) 
poplop(tok) 


clauses 

popval(V)  :- 

retract(valdb([VIVt])) . 

assert(valdb(Vt)),L 
pushval(V)   :- 

retract(valdb(  Void)) , 

assert(valdb([VIVold])),l. 

poplop(L)  :- 

retract(lopdb([LILt])) . 

assert(lopdb(Lt)).!. 
pushlop(L)   :- 

retractdopdb(Lold)). 

assert(lopdb([LILold])).l. 
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I* 

/« 


scanner.inc 


V 


predicates 

scan(string.tokl) 
makeop(string.char.tok) 
maketok(string.tok) 
isres(string) 


clauses 

scan("".[D   :-       !. 
scan(Str.[ToklTokl])   :- 

fronttoken(Str,Cl.Str2). 

frontchar(Str2.C2.Str3), 

makeop(Cl,C2.Tok). 

scan(Str3.Tokl). 

scan(Str,[ToklTokl])  :- 

fronttoken(Str,Sym,Str2). 

maketok(Sym,Tok). 
scan(Str2.Tokl). 


makeop(">",  '•>',  op(">="))- 
makeop("<", '-',  op("  <-")). 
makeop("<",  '>',  op("<  >")). 
makeopC".".  '.'.  opC..")). 


maketok(S,op(S))    :-    isres(S),  !. 
maketok(S.name(S))  :-    isname(S),  !. 
maketok(S,int(N))   :-    str_int(S.N), !. 
maketok(S,opl(C))   :-    str_char(S.C),  !. 


isres(S) 


S  -  "in";  S  -  "and";  S  =  "or"; 

S  -  "xor";  S  -  "eqv";  S  -  "imp"; 

S  -  "not";  S  -  "therexist": 

S  -  "forall";  S  -  "numberof". 
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I*  "operators.inc"  */ 

/«       =„__, ________=       */ 


predicates 
lop(tok) 
relop(tok) 

evalropdok. integer  .integer  .symbol) 

preced(tok.tok) 

evallop(tok.symbol.symbol,symbol) 


clauses 

/*        Determination  of  the  precedence  order         */ 
/*        between  two  logical  operators.  */ 

/«        «/ 

preced(op(T),op("or"))    :- 

T-   "or".   !; 

T-  "xor".  !; 

T  »  "imp",   !; 

T  -  "eqv". !; 

pushlop(op("or")).  !.  fail. 
preced(op(T).op("xor"))   :- 

T  -  "xor".   !: 

T-  "imp".   !; 

T-  "eqv",  !; 

pushlop(op("xor")).  !,  fail. 
preced(op(T).op("imp"))   :- 

T-  "imp".   !; 

T-  "eqv".  !; 

pushlop(op("imp")),   !.  fail. 
preced(op(T).op("eqv"))   :- 

T=  "eqv",   !; 

pushlop(op("eqv")),   !.  fail. 
preced(op(_).T)   :- 

pushlop(T).   !.  fail.  /«  save  op('C)    V 
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/*       Evaluation  of  logical  expression  */ 

/«     «/ 

evallop(opCand"),Vl.V2,Vf)   :- 

VI  -  true.  V2  -  VI.  Vf  -  VI: 

Vf  -  false. 
evallop(op("or"  ).Vl.V2.Vf)  :- 

VI -true.  Vf-Vl; 

V2-true.  Vf-V2; 

Vf  -  false. 
evallop(op("xor"),Vl,V2.Vf)   :- 

VI  <>  V2.  Vf  -  true: 

Vf  -  false. 
evallop(op("imp"),Vl.V2.Vf)   :- 

VI -true.  Vf-Vl; 

V2-V1.  Vf-true: 

Vf  -  false. 
evallop(op("eqv").Vl,V2.Vf)   :- 

VI  -  V2.  Vf  -  true; 

Vf  =  false. 


/*       Categories  of  operators  */ 

/» »/ 


relopCopl(T)) 

relop(op(T)) 

lop(opm) 


T->".  !;     T-'<\  !:     T  -  '  =  ',  !. 
T-">-",   !:     T-"<-".  !:     T  =  "<>" 
-    T  —  "and",  !:     T  -  "or".   !:     T  =  "xor",   !: 
T  =  "imp",   !;     T  -  "eqv". 


/*        evaluation  of  relational  expression  */ 

/« «/ 

evalrop(opl(P).Vl.V2.true)  :-  P=>\  V1>V2. 
evalrop(opl(P).Vl,V2.true)  :-  P='<\  VKV2. 
evalrop(opl(P).Vl,V2.true)   :-       P=='.  V1-V2. 

evalrop(opl  (_)._,_,  Val)    :-  Val=false. !. 

evalrop(op(P).Vl,V2,true)   :-  P=">=".  V1>=V2. 

evalrop(op(P),Vl.V2.true)   :-  P="<=".  VK-V2. 

evalrop(op(P),Vl.V2.true)   :-  P-"o".VK>V2. 
evalrop(op(_),_._.false). 
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Appendix  IV:      Test  Files 


%  "test.simple.pred" 
%  _. 

(x-1)  or  (x=3)  and   (z=y+3)  AZ 


%  "test.qall" 
% 

(forall   i :  (m..n)  :  byte[i]-l)   AZ 


%  "test.qexist" 
% 


(therexist  i :  (2..6)  :  count[i]=5)    *Z 


%  "test.qnum" 
% 

((numberof  i :  (0..7)  :  byte[i]-l)  =  4)    AZ 


%  "test. user" 
% 


(x-1   and  byte[3]=l)  or  (therexist  i :  (1..4)  :  byte[i]=l)  and   x  >  y  *  Z 
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Appendix  V:       Formal  Grammar  for  Definite  Clause  Grammars 

dcg  ::-    lhs   '— >'  rhs 

lhs  ::=    rule__head 

rhs  :>    parse_phrase    ['.'    more_rhs] 

rule_head      ::=    pred_term 

parse_phrase  ::-    [const_term  I  pred_term]# 

pred_term      ::-    string     ['('   arg_list   ')'] 

more_rhs       ::-    extra_cond    [','    rhs]* 

extra_cond     ::=     '{'  semantic_rule    [';'  semantic_rule]*    '}' 

semantic_rule    ::-    users_proc_call  I  system_call 

users_j>roc__call  ::=    procedure_name    ['('  arg_list   ')'] 

procedure_name  ::■=    {  a  procedure_name  is  the  name  of  a  predicate  which 
is  defined  in  the  program  by  the  user  ) 

system_call       :>    {  a  system  call  can  be  any  built-in  function  described 
in  the  C-Prolog  user's  manual) 

const_term   ::=    '['    [const  I  var]   ']' 

compd_term   ::-    (string  I  var)    ["('  arg_list   ')'] 

arg_list  ::-    argument    [','   argument] 

argument  ::=    list  I  term 

list   ::«     '['   term     [terml  I   term2]   ']' 

term   ::=    var  I   const  I  compd term 

terml  ::=     T    term 

term2  ::=    [','  term]# 
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var    ::-    cap_letter    [alphabet  I  digit] 
const  :>    string  I  numeral  I  atom 
string     ::=    small_letter    [alphabet  I   digit] 
alphabet  :>    small_letter  I  cap_letter 
numeral   ::=     [digit]# 
small_letter  ::=    'aTbTc'  ....  I'xTyTz' 
cap_letter    ::«    'ATBTC'I ....  I'XTYTZ' 
digit ::=    '0T1T2T3T4T5T6T7T8T9- 
atom   :>    (  any  printable  character  ) 

Notes: 

I.       The  following  are  the  interpretations  for  some  notations  used  in  the  BNF: 

1)  A  small-letters  string  is  a  nonterminal,  such  as  "dcg". 

2)  A  term  within  a  pair  of  "'"  is  a  terminal,  where  a  terminal  can  be  a  letter,  a  constant 
or  an  atom,  such  as  '0',  '{',  and  '— >'. 

3)  The  repetition  of  terms  can  be  expressed  in  several  ways: 

(termllterm2)   =  either  terml  or  term2  occurs,  and  it  does  once, 
[term]    —   term  occurs  at  most  once. 
[term]#  ■—   term  occurs  at  least  once, 
[term]*  —  term  occurs  zero  or  more  times. 


II.      The  non-terminal  "system_call"  can  be  any  built-in  function  defined  in 
C-Prolog  user's  manual  (Version  1.4). 
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Abstract 

Prolog  is  an  excellent  language  for  developing  parsers  because  Prolog  rules 
are  similar  to  BNF  rules  and  the  Prolog  execution  algorithm  is  similar  to  the 
LL(1)  parsing  algorithm.  This  report  presents  a  study  of  Definite  Clause  Gram- 
mars for  the  parsing  using  Prolog.  Definite  Clause  Grammars  (DCGs)  are  an 
extension  of  Context  Free  Grammars  (CFGs). 

This  report  presents  a  tutorial  on  the  use  of  Definite  Clause  Grammars. 
Also,  a  formal  grammar  for  DCGs  is  given.  As  a  sample  problem,  a  small 
language  interpreter  is  implemented  with  the  use  of  a  DCG  is  written  in  C- 
Prolog.  For  comparison,  another  version  without  the  use  of  a  DCG  is  imple- 
mented in  Turbo  Prolog.  The  two  implementations  are  compared  first  on  syntac- 
tical measurement  and  second  on  subjective  evaluation.  The  syntactical  measure- 
ment consists  of  counts  of  the  constituents  for  each  predicate.  The  subjective 
evaluation  describes  the  degree  of  user  effort  required  for  the  program  design  and 
coding,  and  the  overall  readibillty  of  the  resulting  program. 

From  the  aspect  of  implementation  design,  the  use  of  a  DCG  for  Prolog  pars- 
ing is  preferred  despite  the  possibility  of  higher  syntactical  complexity. 


